_id,_item,_version,_commit,description,tags,date,pdf-url,nature,title,url,timestamp,pdf-content,decision,_item_full_hash
1,1,1,952,"A financial penalty of $9,000 was imposed on Century Evergreen for failing to put in place reasonable security arrangements to protect the personal data of jobseekers in its possession or under its control.","[""Protection"", ""Financial Penalty"", ""Employment"", ""URL manipulation""]",2023-09-15,https://www.pdpc.gov.sg/-/media/Files/PDPC/PDF-Files/Commissions-Decisions/GD_Century_Evergreen_260723.pdf,Protection,Breach of the Protection Obligation by Century Evergreen,https://www.pdpc.gov.sg/all-commissions-decisions/2023/09/breach-of-the-protection-obligation-by-century-evergreen,2023-09-15,"PERSONAL DATA PROTECTION COMMISSION

[2023] SGPDPCS 5

Case No. DP-2212-C0526
In the matter of an investigation under section 50(1) of the
Personal Data Protection Act 2012
And
Century Evergreen Private Limited

SUMMARY OF THE DECISION

1. On 11 December 2022, the Personal Data Protection Commission (the
“Commission”) received a complaint against Century Evergreen Private Limited
(the “Organisation”) that images of identification documents (which includes the
National Registration Identity Card) submitted by jobseekers to the Organisation
were publicly accessible on the Organisation’s website (“Incident”). The
Organisation is a manpower contracting services company and required
jobseekers to submit their identification documents to verify the identity of and
suitability of the jobseeker in question.

2. Following the complaint received, the Commission commenced investigations to
determine the Organisation’s compliance with the Personal Data Protection Act
2012 (“PDPA”). The Organisation requested that the investigation be handled
under the Commission’s Expedited Decision Procedure (“EDP”). This means that
Page 1 of 5

the Organisation voluntarily provided and admitted to the facts set out in this
decision. The Organisation also admitted that it failed to implement reasonable
security arrangements to protect the personal data in its possession and control,
and was in breach of section 24(a) of the PDPA.

3. The Organisation admitted that the Insecure Direct Object References (“IDOR”)
vulnerability on its website, which allowed the complainant to manipulate the URL
had existed from the time the website was launched on 9 November 2015. As a
result of this vulnerability, 96,889 images of identification documents belonging to
23,940 individuals were downloaded from the Organisation’s website from 10 to 12
December 2022.

4. The Organisation admitted that it was in breach of section 24(a) of the PDPA as it
failed to include any security requirements to protect personal data in its contract
with the vendor who first developed and subsequently maintained the website. In
this regard, even though the Organisation had engaged an IT vendor from the time
the website was developed and launched, the Organisation remained solely
responsible for protecting the personal data in its possession and control at all
material times.

5. What is expected from organisations who engage professional services to build
their websites and other online portals is explained in the Commission’s Guide on
Building Websites for SMEs (revised 10 July 2018) (the “Guide”). The Commission
had consistently advised organisations of the need to emphasise the protection of

Page 2 of 5

personal data to their IT vendors, by making it part of their contractual terms.1 The
contract should clearly state the responsibilities of the IT vendor with respect to the
PDPA. In this regard, the Commission noted that there was a glaring omission of
clauses to protect personal data in the Organisation’s contract with its IT vendor.

6. The Organisation also admitted that apart from conducting functionality testing
when the website was first launched, the Organisation had no arrangements with
its IT vendor to conduct any security tests prior to the launch of the website, or
thereafter. The Organisation had also failed to impose any security requirements
on the IT vendor to protect personal data, via contract.

7. In view of the above, the Deputy Commissioner found that the Organisation had
contravened section 24(a) of the PDPA.

8. In deciding the appropriate outcome in this case, the Commission considered that
a financial penalty ought to be imposed as the personal data affected included not
just the identification numbers, but the images of the identification documents.
Furthermore, there was a long period of non-compliance. The vulnerability was not
addressed since 2015.

9. In deciding on the appropriate amount of financial penalty, the circumstances set
out above and the factors listed at section 48J(6) of the PDPA were considered,
specifically the impact of the personal data breach on the individuals affected and
the nature of the Organisation’s non-compliance with the PDPA. In the
circumstances, this was not an insignificant breach given the number of individuals

See Guide on Building Websites for SMEs (revised 10 July 2018) at [4.2.1] and Re EU Holidays Pte Ltd [2019]
SGPDPC 38.
Page 3 of 5

affected (ie 23,940) and the nature of personal data exfiltrated: 96,889 images of
identification documents.
10. The Organisation’s non-compliance with the PDPA was also not simply one of
mere negligence but that of gross negligence. There was a long period of noncompliance on the facts of this case. As set out above, the Commission had issued
the Guide to assist SMEs, and consistently cautioned the need for organisations
to ensure compliance with the PDPA even when they engage an IT vendor in our
previous decisions.2

11. In deciding on the appropriate amount of the financial penalty, the following factors
were considered – the Organisation’s turnover and profitability, its cooperation
throughout the investigation, its voluntary admission of breach of the Protection
Obligation under the EDP, and the prompt remedial actions taken after the
Organisation became aware of the IDOR vulnerability. This included rectifying the
IDOR vulnerability, making server configuration changes to improve security,
implementing vulnerability scans, migrating its backup server to an encrypted
remote server, deploying additional security software and subscription to security
services, and securing a new contract with its vendor to manage the security of its
website. In addition to its prompt remedial actions, its poor performance in the most
recent financial year was also taken into consideration. Finally, the organisation
had admitted to its culpability at an early stage and elected to proceed under the
EDP.

Re EU Holidays Pte Ltd [2019] SGPDPC 38 and Re Vhive Pte Ltd (Case No. DP-2013-B8138).
Page 4 of 5

12. For the reasons above, the Deputy Commissioner for Personal Data Protection
hereby finds the Organisation in breach and directs the Organisation to pay a
financial penalty of S$9,000 within 30 days from the notice accompanying date of
this decision, failing which interest at the rate specified in the Rules of Court in
respect of judgement debts shall accrue and be payable on the outstanding amount
of such financial penalty until the financial penalty is paid in full.

The following section of the Personal Data Protection Act 2012 had been cited in the
above summary:
Protection of personal data
24. An organisation shall protect personal data in its possession or under its control
by making reasonable security arrangements to prevent –
(a) unauthorised access, collection, use, disclosure, copying, modification, disposal or
similar risks; and
(b) the loss of any storage medium or device on which personal data is stored.

Page 5 of 5

",Financial Penalty,3a409dde7f16bfa6ec2d01d5c2d7e80c9ec98146
2,2,1,952,"A financial penalty of $3,000 was imposed on Autobahn Rent A Car for failing to put in place reasonable security arrangements to protect the personal data in its possession or under its control. Directions were also issued to strengthen access control measures to administrator accounts and to conduct reasonable security review of technical and administrative arrangements for the protection of personal data.","[""Protection"", ""Financial Penalty"", ""Directions"", ""Others""]",2023-09-15,https://www.pdpc.gov.sg/-/media/Files/PDPC/PDF-Files/Commissions-Decisions/GD_Autobahn-Rent-A-Car-Pte-Ltd_090623.pdf,Protection,Breach of the Protection Obligation by Autobahn Rent A Car,https://www.pdpc.gov.sg/all-commissions-decisions/2023/09/breach-of-the-protection-obligation-by-autobahn-rent-a-car,2023-09-15,"PERSONAL DATA PROTECTION COMMISSION

[2023] SGPDPCS 4

Case No. DP-2210-C0345

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

And

Autobahn Rent A Car Pte. Ltd.

SUMMARY OF THE DECISION

On 21 October 2022, Autobahn Rent A Car Pte. Ltd. (the “Organisation”)

notified the Personal Data Protection Commission (the “Commission”) of a personal
data breach (the “Incident”).

The Organisation operates a car-sharing service, Shariot, in Singapore. On 24

September 2022, the Organisation received customer feedback that a photograph on
its mobile application had been replaced with a pornographic photograph. The
Organisation discovered that the pornographic photograph had been uploaded
through an unrevoked administrator account belonging to an ex-employee, who had
Page 1 of 6

left the Organisation in May 2022. The ex-employee received an email from an
unknown sender on 10 September 2022 stating that his personal laptop had been
hacked and demanding Bitcoins as ransom payment. The threat actor was able to log
into the Shariot’s mobile application administrator portal through the administrator
account belonging to the ex-employee, and used the export CSV function to download
a copy of the Shariot’s users personal data.

Subsequently, on 21 October 2022, a cybersecurity solutions provider alerted

the Organisation of a cybercrime forum post offering the sale of a Shariot database
containing personal data. The Commission commenced investigations to determine
whether the Incident disclosed any breaches of the Personal Data Protection Act 2012
(“PDPA”) by the Organisation.

The Organisation requested, and the Commission agreed, for this matter to

proceed under the Expedited Decision Breach Procedure. To this end, the
Organisation voluntarily and unequivocally admitted to the facts set out in this decision.
It admitted to a breach of the Protection Obligation under Section 24 of the PDPA.

The Organisation’s internal investigations discovered that compromise of the

dormant administrator account credentials enabled the unauthorised access to Shariot
backend admin web portal, leading to the exfiltration of 53,000 personal data sets of
Shariot users. The personal data that were affected in the Incident included names,

Page 2 of 6

email addresses, mobile phone numbers, NRIC numbers and general location data
(e.g. Bishan, Toa Payoh or Orchard).

Following the Incident, the Organisation took the following remedial action:
(a)

Immediately conducted an internal audit of its administrator accounts to

ensure that any employee access that was not required was revoked;
(b)

Enhanced its software code and admin panel user interface to mask

displayed or exported NRIC numbers to show only the last 4 characters; and
(c)

Conducted cyber hygiene and awareness training for all staff handling

personal data.

The Organisation admitted that it had failed to ensure it had reasonable security

arrangements in place to prevent the unauthorized access or disclosure of the
personal data in its possession or control, as it failed to implement and ensure
reasonable access control to its backend admin web portal. First, the Organisation
failed to revoke the login credentials of an administrator account belonging to an exemployee once the employment relationship came to an end in May 2022. As a result,
the ex-employee’s administrator login credentials remained active, which – when
compromised – enabled the malicious actor access into its network.

Second, the Organisation also admitted that the Incident would not have

happened if it had implemented multi-factor authentication (“MFA”) as an additional
Page 3 of 6

access control for its administrator accounts that had access to its sizeable user
database. In Re Lovebonito [2022] SGPDPC 3, the Commission had highlighted the
need for organisations to strengthen access control, through the use of a one-time
password (“OTP”) or 2FA/MFA, to such accounts. Indeed, regardless of whether an
account is an administrative account, once an account is granted access rights to a
database containing sensitive personal data records or a significant volume of
personal data that would adversely impact the affected individuals in the event of a
personal data breach, we would encourage organisations to consider implementing
enhanced access controls to the account such as through the use of a OTP or
2FA/MFA to better safeguard the personal data.

For the above reasons, the Organisation was determined to have breached the

Protection Obligation.

The Deputy Commissioner’s Decision
10

In determining whether the Organisation should be required to pay a financial

penalty under Section 48J of the PDPA or if directions would suffice, I considered that
a financial penalty was appropriate as the personal data breach was not insignificant.
In deciding the appropriate financial penalty amount, I first considered all the relevant
factors listed at Section 48J(6) of the PDPA, in particular, the impact of the personal
data breach on the individuals affected and the nature of Organisation’s noncompliance with the PDPA. In this regard, while the NRIC numbers and general

Page 4 of 6

location data was affected, this is less serious than if the NRIC images and specific
GPS location had been disclosed.

In deciding what would be the appropriate financial penalty amount, I also

considered the organisation’s turnover to arrive at a figure that would, in my mind, be
a proportionate and effective amount, to ensure compliance and deter non-compliance
with the PDPA. On the facts of this particular case, the organisation’s turnover has
been taken into consideration to arrive at a proportionate and effective financial
penalty. I also considered the following mitigating factors, which led to a further
reduction in the financial penalty:
(a)

The Organisation was cooperative during the course of our

investigations;
(b)

The Organisation voluntarily admitted to breach of the Protection

Obligation under the Commission’s Expedited Decision Procedure; and
(c)

The Organisation took prompt remedial actions following discovery of

the Incident.

For the reasons above, I hereby require the Organisation to pay a financial

penalty of $3,000 within 30 days of the date of the relevant notices accompanying this
decision, 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.

Page 5 of 6

In addition to the financial penalty imposed, the Organisation is also directed to

do the following:
(a)

Implement processes for systems and applications revocation within a

reasonable window of cessation of need for access by an employee;
(b)

Strengthen access controls measures to administrator accounts with

access to databases holding personal data;
(c)

Conduct reasonable security review of technical and administrative

arrangements for the protection of personal data in possession or under control
of the Organisation within 60 days of the date of this Direction;
(d)

Rectify any security gaps identified in the security review directed above;

and
(e)

Inform the Commission within 1 week of the completion on the steps

directed above.

Page 6 of 6

","Financial Penalty, Directions",458ca2b78344d38cc2dec8a4e89a493c8a7475a2
3,3,1,952,A warning was administered to a registered salesperson of an estate agency for failing to (i) obtain clear and unambiguous consent; or (ii) check the Do Not Call Register before sending specified messages to individuals registered on the Do Not Call Register.,"[""Do Not Call Provision(s)"", ""Warning"", ""Real Estate""]",2023-08-16,https://www.pdpc.gov.sg/-/media/Files/PDPC/PDF-Files/Commissions-Decisions/GD_Leon-Wee_11072023-(004).pdf,Do Not Call Provision&#40;s&#41;,Breach of Duty to Check the Do Not Call Register by a Registered Salesperson,https://www.pdpc.gov.sg/all-commissions-decisions/2023/08/breach-of-duty-to-check-the-do-not-call-register-by-a-registered-salesperson,2023-08-16,"PERSONAL DATA PROTECTION COMMISSION

[2023] SGPDPC 8

Case No. ENF-DNC-221129-0007 & Others

In the matter of an investigation under section 50(1) of the
Personal Data Protection Act 2012
And
Wee Jing Kai Leon

… Person

DECISION

Wee Jing Kai Leon

Wong Huiwen Denise, Deputy Commissioner — Case No. ENF-DNC-221129-0007 &
Others

11 July 2023

Introduction
1

The Do Not Call Registry (“DNC Registry”) is a national database kept and

maintained by the Personal Data Protection Commission (the “Commission”)
pursuant to section 39 of the Personal Data Protection Act 2012 (“PDPA”). Persons
may register their Singapore telephone numbers with the DNC Registry so as to not
receive unsolicited telemarketing calls and messages. The DNC Registry comprises
of 3 separate registers (i) the No Text Message Register, (ii) the No Voice Call
Register, and (iii) the No Fax Message Register.

Between November 2022 and March 2023, the Commission received ten (10)

complaints that one Wee Jing Kai Leon (“Individual”) had sent unsolicited
telemarketing messages to telephone numbers registered on the No Text Message
Register of the DNC Registry (the “Complaints”).

The Commission commenced investigations to determine whether there had

been any breaches of the “Do Not Call” provisions in Part 9 and 9A of the PDPA (“DNC
Provisions”).

Facts of the Case
4

The Individual is a real estate salesperson registered with Propnex Realty Pte

Ltd since 2006. Over the years, the Individual collated a list of 2,918 Singapore
telephone numbers (the “Marketing List”).

Of the 2,918 telephone numbers in the Marketing List, 1,224 were registered

with the No Text Message Register of the DNC Registry on or around 31 March 2023.

The Individual did not send any marketing messages to the telephone numbers

on his Marketing List before November 2022 and only admitted to sending a short
messaging service message each month from November 2022 to March 2023 (the
“SMS Messages”) to the telephone numbers on the Marketing List to offer, advertise
and/or promote his services as a real estate salesperson. According to the Individual,
by November 2022, the challenging business environment had made it more difficult
for him to get leads. He therefore opted to rely on the numbers in the Marketing List to
prospect for leads.

Given that the Marketing List included 1,224 telephone numbers registered on

the DNC Registry, the Individual had sent approximately 6,120 SMS Messages to

telephone numbers registered on the DNC Registry from November 2022 to March
2023.

The SMS Messages bore the sender ID “Propnex LW”, which is registered

under the SMS Sender ID Regime (“SSIR”)1 by DGK Global Pte Ltd (“DGK Global”),
a company owned by the Individual. During investigations, the Individual clarified that
DGK Global was not involved in his real estate business, and that he used DGK Global
to register the sender ID under SSIR because he needed a UEN number to do so.

Findings and Basis for Determination
The Duty to check DNC Registry under section 43(1) of the PDPA
9

The Commission’s investigation focused on whether the Individual had

intentionally or negligently breached section 43(1) of the PDPA by:
(a)

sending “specified messages” addressed to Singapore telephone
numbers,

(b)

without having valid confirmation that the Singapore telephone numbers
were not listed in the DNC Registry at the time the specified messages
were sent.

The SSIR was set up in March 2022 to enable organisations to protect their customers from receiving fraudulent
SMS messages that spoofed the organisations’ SMS Sender IDs. Organisations intending to send SMS messages
to Singapore mobile numbers can register any alphanumeric Sender IDs under the SSIR. The Full SSIR Regime
came into effect from 31 January 2023, upon which all non-registered Sender IDs will be marked as “LikelySCAM” for a transition period of 6 months. Thereafter, messages with non-registered Sender IDs will be blocked
and not delivered to end-users.

“Specified message”
10

A message is a “specified message” if one of its purposes is for: 2
(a)

(b)

Advertising, promoting, or offering to supply or provide:
(i)

goods or services;

(ii)

land or an interest in land;

(iii)

business opportunity or an investment opportunity;

Advertising or promoting a supplier or provider (or a prospective supplier
or provider) of the items listed in sub-paragraphs (i) to (iii) above.

Whether a “specified message” has one of the above purposes is determined

with regard to the following:3
(a)

the content of the message;

(b)

the presentational aspects of the message;

(c)

the content that can be obtained using the numbers, URLs or contact
information (if any) mentioned in the message; and

(d)

if the telephone number from which the message is made is disclosed to
the recipient (whether by calling line identity or otherwise), the content
(if any) that can be obtained by calling that number.

The SMS Messages were “specified messages” within the meaning of the DNC

Provisions, as they were sent for the purpose of advertising and/or promoting the
Individual’s real estate services. The SMS Messages contained statements such as,
2
3

Tenth Schedule to the PDPA.
Section 37(1) of the PDPA.

“Engage Professional & Committed Agent to Sell/Rent your Home.”, and “Whatsapp
Leon Wee directly at https://chatwith.io/s/enquire to rent/sell your property”. They also
included links to the Individual’s website and social media profiles.

The Individual admitted that the SMS Messages were addressed to Singapore

telephone numbers, as also evidenced by the complaints received by the Commission.

Valid confirmation
14

A person can obtain valid confirmation that a Singapore telephone number is

not listed in the DNC Registry by doing the following:4
(a)

Within 21 days before sending the specified message,5 the person can
apply for and receive confirmation from the Commission that the
Singapore telephone number is not listed in the relevant register of the
DNC Registry;6 or

(b)

The person can obtain confirmation that the Singapore telephone
number is not listed in the relevant register of the DNC Registry from a
“checker”,7 but must not have reason to believe that, or be reckless as
to whether the checker’s information was obtained more than 21 days
ago, or is false or inaccurate.

Section 43(2) of the PDPA.
Section 15 of the Personal Data Protection (Do Not Call Registry) Regulations 2013 (the “DNC
Regulations”).
6
Under section 40(2) of the PDPA
7
A “checker” refers to a person that, for a reward, provides to another person (P) information on whether a
Singapore telephone number is listed in the relevant register for the purpose of P’s compliance with Section 43(1)
of the PDPA. A “checker” is a person other than the Commission, an employee of P, and an employee or agent
of a checker.
5

Investigations revealed that the Individual did not obtain valid confirmation that

the telephone numbers on his Marketing List were not listed in the DNC Registry.

Whether the Individual received clear and unambiguous consent
16

Even if a specified message is sent to a Singapore telephone number without

valid confirmation that the number is not listed in the DNC Registry, a person does not
contravene section 43(1) of the PDPA if:
(a)

the subscriber or user of the Singapore telephone number gave clear
and unambiguous consent to the sending of the specified message; and

(b)

the consent is evidenced in writing or other form so as to be accessible
for subsequent reference8. This means that the consent must be
captured in a manner or form which can be retrieved and reproduced at
a later time in order to confirm that such consent was obtained. Possible
forms include an audio or video recording of the consent given9.

In the course of investigations, the Individual represented to the Commission

that he was under the impression that since he had obtained the telephone numbers
prior to the enactment of the PDPA, he could use them for marketing purposes.

The Commission recognises that a subscriber of a Singapore telephone

number is deemed to have given his consent to a person to send a specified message
to that Singapore telephone number if the subscriber consents to the sending of the
8
9

Section 43(4) of the PDPA.
[8.3] of the Advisory Guidelines on the DNC Provisions (revised 1 February 2021)

specified message before 2 January 2014 (i.e. before the DNC Provisions came into
effect), and that consent has not been withdrawn.10 Even if the subscriber
subsequently adds his telephone number to the DNC Registry, this would not amount
to withdrawal of consent.11

However, this does not relieve the Individual of his obligations under section

43(4) to obtain the consent of the subscribers or users of the Singapore telephone
number to which a specified message is sent to him. In other words, if the Individual
intended to rely on section 43(4) of the PDPA, he should have obtained clear and
unambiguous consent to the sending of the SMS Messages to the telephone numbers
in his Marketing List from the subscribers of the Singapore telephone numbers
contained therein evidenced in written or other forms. The Commission sets out, at
[8.5] of the Advisory Guidelines on the DNC Provisions (revised 1 February 2021),
various methods through which such consent can be obtained from the subscribers or
users:
“For example, persons may seek to obtain consent by asking individuals to:
a) respond to a pop-up on a webpage;
b) respond to pop-ups or other form of notifications within mobile applications;
c) fill out and submit a web form;
d) fill out and submit a physical form;
e) indicate their choice by signing or ticking against a check box printed on a
letter or service agreement; or
10
11

Section 47(4) of the PDPA.
Section 47(5) of the PDPA.

f) call or send an SMS to the person.”

The Commission found no evidence of the Individual obtaining such clear and

unambiguous consent from any of the subscribers of the Singapore telephone
numbers on the Marketing List, in written or other forms before or after 2 January 2014.

Accordingly, the Individual failed to obtain valid confirmation that the telephone

numbers in the Marketing List are not listed in the DNC Registry before sending the
SMS Messages, and has negligently contravened section 43(1) of the PDPA.

Whether the Individual is an employee acting in the course of employment
22

For completeness, the Commission assessed whether the defence under

section 48 of the PDPA was available to the Individual, and concluded that it was not.
Section 48(2) provides that section 43(1) does not apply to an employee who sends a
specified message to a Singapore telephone number if he can prove that he did so in
good faith in the course of his employment or in accordance with instructions given to
him by or on behalf of his employer in the course of his employment. The Commission
considered the following:
(a)

In accordance with industry practices, real estate salespersons such as
the Individual are not in an “employer-employee relationship” with their
agencies.

(b)

The Individual confirmed that he is not an employee of Propnex Realty
Pte Ltd (“Propnex”) despite being registered with them. He does not

receive salary from Propnex, nor does Propnex provide the Individual
with medical benefits, CPF contributions, or annual leave benefits. The
Individual is self-employed and does not report to Propnex on the
conduct of his business.
(c)

The contents of the SMS Messages related to the services of the
Individual specifically, and not Propnex.

The Deputy Commissioner’s Decision
23

In determining whether any financial penalties or directions should be imposed

on the Individual, the Commission took the following into consideration:
(a)

The Individual was cooperative with the Commission’s investigations;

(b)

The Individual had otherwise made efforts to ensure his compliance with
other DNC Provisions, in particular the requirement under section 44 of
the PDPA to include clear and accurate information identifying the
sender of the SMS Messages and how he can be readily contacted. He
had also provided recipients the option to unsubscribe from the SMS
Messages, and would remove a recipient’s telephone number from the
Marketing List if so requested; and

(c)

The Individual’s efforts to register the sender ID “Propnex LW” showed
a willingness to comply with regulatory regimes, in particular the SSIR.

Having considered all the factors listed above, the Individual is hereby

administered a warning in respect of his breach of section 43(1) of the PDPA. No other

directions are necessary in view of the Individual’s voluntary cessation of sending
specified messages to numbers on the Marketing List.

The Commission observes that this case occurred alongside media reports of

an increase in property scams. The Commission has also investigated complaints
involving property agents who had concealed their identities while sending marketing
messages in contravention of the DNC Provisions. For the avoidance of doubt, while
there was no evidence that the Individual was involved in any scams or had attempted
to conceal his identity in his marketing messages, the Commission will continue to
monitor this trend involving property agents and calibrate its decisions in future cases
accordingly to ensure compliance with the DNC Provisions of the PDPA.

WONG HUIWEN DENISE
DEPUTY COMMISSIONER
FOR PERSONAL DATA PROTECTION

",Warning,f18593fdbb15638a11bc2083adacad1a58daf1b2
4,4,1,952,"A financial penalty of $74,400 was imposed on Ecommerce Enablers for failing to put in place reasonable security arrangements to protect users' personal data in its possession or under its control.","[""Protection"", ""Financial Penalty"", ""Wholesale and Retail Trade""]",2023-08-16,https://www.pdpc.gov.sg/-/media/Files/PDPC/PDF-Files/Commissions-Decisions/Decision---Ecommerce-Enablers.pdf,Protection,Breach of the Protection Obligation by Ecommerce Enablers,https://www.pdpc.gov.sg/all-commissions-decisions/2023/08/breach-of-the-protection-obligation-by-ecommerce-enablers,2023-08-16,"PERSONAL DATA PROTECTION COMMISSION

[2023] SGPDPC 6

Case No. DP-2009-B7056

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

And

E-Commerce Enablers Pte. Ltd.
… Organisation

DECISION

Page 1 of 11

E-Commerce Enablers Pte. Ltd.
Lew Chuen Hong, Commissioner — Case No. DP-2009-B7056
16 May 2023

Introduction
1

On 25 September 2020, E-Commerce Enablers Pte. Ltd. (“Organisation”)

notified the Personal Data Protection Commission (“PDPC”) and its customers of an
incident involving unauthorised access to its customer data servers (the “Incident”).
PDPC subsequently received 2 complaints from the Organisation’s customers in
relation to the Incident. On 12 November 2020, the Organisation's customer database
was offered for sale on an online forum indicating that personal data was exfiltrated
during the Incident.

PDPC commenced investigations to determine the Organisation’s compliance

with the Personal Data Protection Act 2012 (“PDPA”) in relation to the Incident.

Facts of the Case
3

The Organisation runs an online platform offering cashback for purchases

made through affiliated merchant programs. The platform also provides coupons,
voucher codes, and comparison features with discounts for users.

At the time of the Incident, the Organisation hosted its customer database on

virtual servers in an Amazon Web Services (“AWS”) cloud environment (“Customer
Page 2 of 11

Storage Servers”). The Organisation employed a 12-man Site Reliability Engineering
(“SRE”) team whose responsibilities included maintaining the Organisation’s
infrastructure, providing, and managing the Organisation’s cloud environment on
AWS, and ensuring security of the AWS keys. The SRE team made use of an AWS
access key with full administrative privileges (the “AWS Key”) for the purposes of its
work, including infrastructure deployment. Only SRE team members had access to,
and were authorised to use, the AWS Key. On 4 June 2019, the AWS Key was
inadvertently committed to software code in a private repository in GitHub, by a senior
member of the SRE team. This was discovered by another SRE team member on 6
June 2019, and the AWS Key was removed from GitHub on the same day. However,
it remained viewable in GitHub’s ‘commit history’, which records all changes and
previous versions of code uploaded on GitHub.

On 21 June 2019, the AWS Key was to be deleted and replaced by a new key

as part of an out-of-cycle key rotation. The member of the SRE team in charge of the
key rotation informed the SRE team (via email) that he had created a new key to
replace the AWS Key, and that he would be deleting the AWS Key. However, after
creating the replacement key, he failed to fully disable and remove the AWS Key.

As a result, the AWS Key continued to be usable to access the Organisation’s

AWS environment (and consequently the Customer Storage Servers) until shortly after
the time of the Incident, about 15 months later.

Page 3 of 11

The Incident
7

On 9 September 2020, a malicious threat actor accessed the Organisation’s

AWS environment utilizing the AWS Key. The AWS Key was likely found by the threat
actor in the commit history of the GitHub private repository.

Having gained privileged access to the AWS environment, the threat actor (i)

conducted reconnaissance to identify the Organisation’s data repositories, (ii) modified
security settings including to allow remote internet access to the Organisation’s
database instances (i.e. its virtual servers hosting data), and (iii) generated a fresh
database instance to stage its data exfiltration.

The threat actor then proceeded to exfiltrate data from the Customer Storage

Servers. The data items, and the corresponding number of individuals affected, are
set out below:

Types of personal data
Email Address

Number of affected users
1,457,637

Name

840,210

Mobile number

447,076

Address

138,327

Gender

23,278

NRIC numbers

9,961

Date of birth

202,634

Bank Account number

299,381

Partial credit card information, including:

378,531
Page 4 of 11

(i) partial credit card number (first 6 digits
and last 4 digits)
(ii) issuing bank
(iii) country
(iv) expiry month and year
(v) Visa or Mastercard

On 17 September 2020, the Organisation discovered during a routine security

review that there had been unauthorised access to its AWS environment. Further
investigations revealed that there had been unauthorised third-party access to the
Organisation’s AWS environment.

The Organisation subsequently engaged a private forensic expert, (“PFE”) to

investigate further. The PFE confirmed that the unauthorised access had been carried
out using the AWS Key. The Organisation conjectured that it was likely that the threat
actor had obtained the AWS Key from GitHub’s commit history, where the AWS Key
was still visible despite the removal of the wrongly committed code from the private
repository in GitHub.

Remedial actions
12

Following the Incident, the Organisation implemented the following remedial

measures:
Immediate remedial steps to contain the Incident
(a)

Performed a full deletion of the AWS Key and rotated the other AWS keys;

Page 5 of 11

(b)

Reversed all changes made by the threat actor and triggered a forced
logout and password reset of all customers’ accounts;

To prevent recurrence or similar incidents
(c)

Increased monitoring of logs to ensure heightened detection of any
unauthorised access;

(d)

Separated development and production accounts, resulting in a smaller
subset of engineers having access to the production environment;

(e)

Secured access to systems and data with several measures, including VPN
and IP address whitelisting and database encryption; and

(f)

Created a platform for employee security suggestions / breach reporting.

Subsequent sale of personal data on Raidforums
13

On 12 November 2020, the Organisation’s database was offered for sale on

Raidforums, an online cybersecurity forum commonly used for trading and selling of
stolen databases. Raidforums’ domain name and content was independently seized
by authorities from the United States in April 2022.

Findings and Basis for Determination
14

Based on the circumstances of the Incident, the Commission’s investigation

centred on whether the Organisation had breached its obligations under section 24 of
the PDPA to protect personal data in its possession or under its control, by making
reasonable security arrangements to prevent unauthorised access, collection, use,
Page 6 of 11

disclosure, copying, modification, disposal, or similar risks (the “Protection
Obligation”). The Organisation was determined to have breached the Protection
Obligation in two respects.

Lack of sufficiently robust processes for AWS key management
15

First, the Organisation failed to ensure that processes to manage the AWS keys

that granted access to the Customer Storage Servers were sufficiently robust.

While the Organisation admitted that it could have done more to ensure that its

employees were performing their AWS key rotation duties properly, the Organisation
claimed that the compromise of the AWS Key arose from human error, and not
because of any systemic issue with the Organisation’s security practices. According
to the Organisation, there was no reason to doubt the capabilities of the SRE team
member in question, because (i) he was a senior member of the SRE team, (ii) his
responsibilities included key security and rotation, and (iii) he had dutifully rotated /
deleted all other keys assigned to him in the out-of-cycle key rotation. The SRE team
member’s inadvertent commit, and an incomplete rotation/deletion were in direct
contravention of the Organisation’s security practices. The Organisation accordingly
sought to frame the Incident as a one-off case of human error.

This position is not accepted. As explained in Re DataPost Pte Ltd,

Organisations cannot place sole reliance on their employees to perform their duties
properly as a security arrangement to protect personal data. There must be some
Page 7 of 11

processes to ensure that the step required from the employee is taken, such as
independent verification by another checker1.

For example, a precaution the Organisation could have taken to ensure that the

out-of-cycle key rotation was complete would have been to have a supervisor or
another SRE team member test either all or a reasonable sample of the old keys
(depending on the number of keys being rotated) to verify that they had been disabled.
There was no such verification or testing practice put in place by the Organisation; the
Organisation relied wholly on the SRE team member’s seniority and experience.

When a high-risk task (e.g. rotation of an AWS key that gives access to the

whole of the AWS environment) is concerned, it is all the more important that there
must be additional verifications and checks.

Failure to conduct periodic security review
20

Second, specific security review by the Organisation on AWS keys could have

covered and detected whether the AWS Key remained active or had been used after
the out-of-cycle key rotation, and during the 15 months preceding the Incident. The
Organisation failed to conduct regular security review on whether the AWS keys had
been properly rotated/deleted. In the course of investigations, the Organisation
acknowledged that it could have done more to ensure that the SRE team was
performing their AWS key rotation duties properly. Following the Incident, the
1 Re DataPost Pte Ltd [2017] SGPDPC 10, at [13] – [16]

Page 8 of 11

Organisation implemented a more secure process for temporary, time-limited keys to
be issued to SRE team members whenever access to the AWS environment was
required. The Organisation also developed a specific IT security policy concerning the
secure sharing of keys internally.

Observation on the incident management processes
21

Following discovery of the inadvertent committal of the AWS Key to GitHub, the

Organisation took 15 days to conduct a key rotation. Regardless of whether this had
been an out-of-cycle rotation, the Organisation should review its incident management
processes to determine whether it was reasonable to have taken 15 days to remediate
compromise of a full administrative privilege AWS access key.

The Commissioner’s Decision
22

In determining whether to impose a financial penalty on the Organisation

pursuant to section 48J(1) of the PDPA, and the amount of any such financial penalty,
the matters set out at section 48J(1) and the factors listed at section 48J(6) of the
PDPA were taken into account, including the following aggravating and mitigating
factors:
Aggravating Factors
(a)

The Organisation lacked sufficiently robust processes to monitor its incident
management response to ensure reasonable remediation speed, which led
to 15 days passing before the Organisation responded to the exposure of
the AWS Key;
Page 9 of 11

(b)

The AWS Key was exposed for a long period of 15 months;

Mitigating Factors
(a)

The Organisation took prompt remedial actions, including notifying the
affected individuals;

(b)

The Organisation was cooperative during investigations; and

(c)

The Organisation voluntarily acknowledged that its failure to ensure proper
rotation and deletion of the AWS Key constituted a breach of the Protection
Obligation.

The Organisation was notified of the preliminary decision by way of the

Commission’s letter dated 15 February 2023 and was invited to make representations
on the same. The Organisation made representations on 22 March 2023, albeit not on
its liability for breaches of the Protection Obligation or on the proposed financial
penalty. Where accepted by the Commission, these representations have been
incorporated into this decision.

Having considered all the relevant circumstances of this case, the

Commissioner hereby requires the Organisation to pay a financial penalty of $74,400
within 30 days from the date of the relevant notice accompanying this decision, 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.
Page 10 of 11

No further directions are necessary on account of the remedial measures

already taken by the Organisation.

Page 11 of 11

",Financial Penalty,76e1a0c6ce1eec405d0c28dbde5757aff32b2192
5,5,1,952,"A financial penalty of $58,000 and $10,000 was imposed on Fullerton Healthcare and Agape CP Holdings respectively for failing to put in place reasonable security arrangements to protect personal data belonging to Fullerton Healthcare’s corporate clients and direct patients. Directions were also issued to both organisations to review and enhance processes relating to data handling processes, security audits and access controls to bolster their data protection arrangements.","[""Protection"", ""Financial Penalty"", ""Directions"", ""Healthcare"", ""Public access""]",2023-06-22,https://www.pdpc.gov.sg/-/media/Files/PDPC/PDF-Files/Commissions-Decisions/GD_Fullerton-Healthcare-Group-and-Agape-CP-Holdings_230323.pdf,Protection,Breach of the Protection Obligation by Fullerton Healthcare and Agape CP Holdings,https://www.pdpc.gov.sg/all-commissions-decisions/2023/06/breach-of-the-protection-obligation-by-fullerton-healthcare-and-agape-cp-holdings,2023-06-22,"PERSONAL DATA PROTECTION COMMISSION

[2023] SGPDPC 5
Case Nos. DP-2110-B9054 / DP-2110-B9060

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

And

(1)

Fullerton Healthcare Group Pte Limited
(UEN No. 201020358N)

(2)

Agape CP Holdings Pte. Ltd.
(UEN No. 201435153E)

… Organisations

DECISION

(1) Fullerton Healthcare Group Pte Limited
(2) Agape CP Holdings Pte. Ltd.

Lew Chuen Hong, Commissioner — Case Nos. DP-2110-B9054 / DP-2110-B9060
23 March 2023

Introduction

On 19 October 2021 and 21 October 2021, Fullerton Healthcare Group Pte

Limited (“FHG”) and Agape CP Holdings Pte. Ltd. (“Agape”) respectively notified the
Personal Data Protection Commission (the “Commission”) that the personal data of
FHG’s customers had been accessed, exfiltrated, and offered for sale on the dark web
(the “Incident”). The Commission commenced investigations to determine whether
the Incident disclosed any breaches of the Personal Data Protection Act 2012
(“PDPA”) by FHG and Agape.

On 11 January 2022 and 12 January 2022 respectively, FHG and Agape

requested for the investigations to be handled under the Commission’s Expedited
Decision Procedure. In this regard, FHG and Agape voluntarily provided and admitted
to the facts set out below and admitted that they had failed to implement reasonable

security arrangements to protect the personal data accessed and exfiltrated in the
Incident in breach of section 24 of the PDPA (the “Protection Obligation”).
Facts of the Case

FHG is an enterprise healthcare service provider which provides healthcare

services to individuals and employees of its corporate clients. In 2018, FHG engaged
Agape, a business process outsourcing provider and social enterprise, to provide call
centre and appointment booking services for its customers (the “Services”). As part
of its social enterprise initiatives, Agape engaged inmates from Changi Women’s
Prison (the “Agents”) to assist in provision of the Services for FHG’s customers.

In order to carry out the Services, FHG provided Agape with access to the

personal data of its customers via Microsoft SharePoint, a cloud-based document
management system. A single Agape personal computer (the “Computer”) was
authorised to access FHG’s SharePoint platform via an FHG-assigned SharePoint
account.

In order to facilitate Agents’ access to FHG’s customer data from within Changi

Women’s Prison, Agape downloaded FHG’s customer data onto the Computer, and
re-uploaded the customer data onto an internet-facing file server (“the Online Drive”).
The Online Drive was then white-listed for access by the Agents from within Changi
Women’s Prison.

The Incident
6

On 15 October 2021, FHG became aware that its customer data was being

offered for sale on a dark web forum. FHG engaged cybersecurity consultants to
investigate. On 18 October 2021, FHG’s cybersecurity consultants made contact with
the purported seller who claimed that he had exfiltrated FHG’s customer data from
Agape’s Online Drive. By 22 October 2021, the post on the dark web forum advertising
the sale had been removed.

FHG’s cybersecurity consultants confirmed that the Incident solely involved and

affected Agape’s Online Drive. FHG’s own systems and servers were not affected in
the Incident.

The personal data of 156,900 FHG customers (133,866 direct patients and

23,034 employees of FHG’s corporate clients) was accessed without authorisation in
the Incident, although the exact volume of exfiltrated personal data was unknown. The
affected personal data comprised the following datasets:
Direct patients
(a)

Name;

(b)

NRIC number / FIN;

(c)

Date of birth;

(d)

Gender;

(e)

Email address;
4

(f)

Telephone number;

(g)

Financial information (Bank account numbers and bank codes);

(h)

Health information (International Classification of Diseases codes that pertain

to an individual’s diagnosis information, and codes for surgical procedures done in
hospitals);
Employees of FHG’s corporate clients
(i)

Name;

(j)

NRIC number / FIN / Passport number;

(k)

Date of birth;

(l)

Email address;

(m)

Financial information; and

(n)

Health, and other information (Information relating to the utilisation of health

benefits by individual members, which include details of clinic names and claim
amount
(collectively, the “Customer Data”).

Remedial actions
9

As part of remedial measures following the Incident, FHG informed affected

clients and individuals promptly via SMS, email, and an FAQ page on its website,
advising on appropriate steps which could be taken to guard against potential risks.
FHG also engaged Credit Bureau (Singapore) Pte Ltd to provide free credit monitoring
services to affected individuals for 6 months.

Agape suspended use of the Online Drive with effect from 19 October 2021,

and, with the assistance of a forensic team, conducted internal checks on the
Computer and Online Drive for other indicators of compromise.

FHG in coordination with Agape also:

(a)

restricted Agape’s access to its SharePoint to “view-only”;

(b)

deleted SharePoint files and folders that Agape did not need as part of data

minimisation efforts;
(c)

ceased synchronisation of data between SharePoint and the Computer;

(d)

changed all passwords for Agape’s access to FHG’s SharePoint; and

(e)

deleted the Customer Data from the Online Drive upon completion of Agape’s

investigations into the Incident.

Findings and Basis for Determination

Whether Agape had contravened the Protection Obligation
12

As a data intermediary of FHG, Agape is subject to the Protection Obligation

pursuant to section 4(2) of the PDPA. For the reasons set out below, Agape was
determined to have breached the Protection Obligation in relation to the Customer
Data affected in the Incident.

Failure to conduct reasonable periodic security reviews
13

In previous enforcement decisions, the Commission has emphasised the need

for organisations to conduct periodic security reviews of their IT systems. Such reviews
enable organisations to detect vulnerabilities, assess security implications and risks,
and ensure that reasonable security arrangements are implemented to eliminate or
mitigate such risks. Periodic security reviews should be scoped based on the
organisation’s assessment of its data protection needs, for example, taking into
account the type of personal data to be protected.1

In Quoine Pte Ltd [2022] SGPDPC 2 (“Quoine”), while the organisation had

conducted periodic security reviews, these security reviews were improperly scoped
and failed to include a particular account. The organisation explained that its current
staff were not aware of the reasons for the affected account’s set-up and security
arrangements, as the account had been created “at some time in the past (so legacy)”.
This explanation did not excuse the organisation’s breach of the Protection Obligation.
The Commission found that it was incumbent on the organisation to have implemented
the necessary systems and processes to ensure that critical information about its
systems, including legacy systems, survived the turnover of its staff (Quoine at [23]).

Similarly, while Agape had carried out periodic security reviews, these reviews

failed to cover the Internet-facing Online Drive. Agape admitted that this omission was

Everlast Projects Pte Ltd and others [2020] SGPDPC 20 (at [21]).

because the use of the Online Drive had been a legacy feature unique to Agape’s
engagement by FHG, which was not implemented for any of Agape’s other clients. As
a result of this omission, Agape failed to review and assess the Online Drive’s security
implications and risks.

When the Online Drive was installed in December 2017, it was protected by a

password which met Agape’s password complexity policy (i.e. 8 to 10 characters with
a mix of upper and lower-case characters, numbers and symbols). However, at the
time of the Incident, the password for Agape’s Online Drive had been inadvertently
disabled for an estimated 20 months (since December 2019), the cause of which could
not be established. Agape admitted that this caused the Online Drive to become an
open directory listing on the Internet with no password protection, and highly
vulnerable to unauthorised access, modification and similar risks over an excessive
period of time.

If Agape’s periodic reviews had been properly scoped to cover all of the IT

components under its Services rendered to FHG (including the Online Drive), this
lapse could have been detected and rectified timeously.

Inadequate password policy and management
18

In the course of investigations, Agape also admitted that prior to the password

being disabled in December 2019, it had been shared by Agents to access the Online

Drive. In Terra Systems Pte. Ltd. [2021] SGPDPC 72, the Commission highlighted the
data protection risks associated with multiple users sharing a common password,
including greater risks of unauthorised access by ex-staff and inadvertent disclosure
to threat actors through social engineering, among others.

The use of a common password among all Agents was exacerbated by the fact

that there was no expiry date set for the password. The failure to implement and
enforce reasonable password management policies increased the vulnerability of the
Customer Data on the Online Drive to unauthorised access and other similar risks,
even before the password had been disabled.

For the above reasons, Agape was determined to have breached the Protection

Obligation.

Whether FHG had contravened Section 24 of the PDPA
Failure to exercise reasonable oversight of vendor
21

Under Section 4(3) of the PDPA, an organisation that engages a data

intermediary to process personal data on its behalf, bears the same obligations under
the PDPA as if the personal data was processed by the organisation itself. This is so,
even where the organisation engages the data intermediary to implement the

This decision was subsequently subjected to reconsideration by the Commission. In Terra Systems
Pte Ltd [2022] SGPCPCR 1, the Commissioner affirmed the finding of the organisation’s breach of
Section 24 of the PDPA and the financial penalty imposed.

necessary data protection measures in relation to the personal data (Social Metric Pte
Ltd [2017] SGPDPC 17 at [15]).

The Commission has reiterated in past decisions, such as SCAL Academy Pte.

Ltd. [2020] SGPDPC 2, that the Protection Obligation requires organisations to
exercise reasonable oversight of their vendors.

Specifically in the context of an organisation’s relationship with its data

intermediary, the organisation (i.e. the data controller) has a supervisory or general
role for the protection of the personal data, while the data intermediary has a more
direct and specific role in the protection of personal data arising from its direct
possession or control over the personal data. This means that a data controller may
be found in breach of the Protection Obligation, even though its data intermediary may
not be found in breach, and vice versa (Social Metric Pte Ltd [2017] SGPDPC 17 at
[16]).

In this case, FHG engaged Agape as its data intermediary to carry out the

Services using the personal data provided by FHG. Under the Protection Obligation,
FHG was required to exercise reasonable oversight of Agape’s data processing
activities.

In SCAL Academy Pte. Ltd. [2020] SGPDPC 2 (at [8]), even though the

organisation in question had instructed its vendor to prevent certain documents from
10

being ‘leaked’ online, it did not check what security arrangements the vendor had
implemented to ensure this. This hindered the organisation and vendor from being
able to identify any data protection risks and agree on the measures to be implemented
to protect against unauthorised disclosure of the personal data in the documents.

In this case, due consideration is given to the fact that FHG had conducted a

high-level IT due diligence review of Agape prior to its decision to onboard Agape as
a vendor, and that FHG’s written agreement with Agape required the latter to comply
with the PDPA including, among others, obligations to take all appropriate and
reasonable administrative, physical and technical safeguards, and security
arrangements. Nevertheless, FHG’s failed to exercise reasonable oversight through
regular monitoring of Agape’s personal data handling processes throughout the
engagement, including how Agape stored and granted Agents’ access to the
Customer Data.

In this regard, there was a point of contention between the parties over whether

FHG was aware of and permitted the uploading of the Customer Data from Agape’s
Computer to the Internet-facing Online Drive.

According to FHG, its understanding with Agape was that the local copy of the

Customer Data on the Computer was only to be used for emergency or exceptional
situations such as when Agape was unable to connect to FHG’s SharePoint during
any system downtime or disruptive event. No other copies of the Customer Data were
11

to be made by Agape, whether from the SharePoint or the local copy on the Computer.
FHG stated that it did not provide Agape with permission to upload the Customer Data
from Agape’s Computer to the Online Drive.

In contrast, Agape asserted that FHG was aware that the Agents were inmates

operating from inside Changi Women’s Prison, and that there were IT restrictions
preventing them from accessing the Customer Data directly from FHG’s Sharepoint.
As such, Agape had downloaded and uploaded the Customer Data onto its Online
Drive for the Agents to access and use. Agape asserted that FHG was aware of
Agape’s process of sharing Customer Data with the Agents as FHG’s representatives
had been present during “dry runs”.

While there was insufficient contemporaneous evidence to support either

party’s version of events, the fact remains that FHG was aware that Agape was
engaging inmates from inside Changi Women’s Prison to carry out the Services, and
the Commission’s findings regarding FHG’s breach of the Protection Obligation are
not dependent on whether FHG permitted Agape to upload the Customer Data to the
Online Drive or not.

Given that FHG was aware that access to the Customer Data would have to be

granted to a third party that was offsite for the provision of the Services, FHG should
have made reasonable enquiries to ascertain how the Customer Data was to be stored
and transmitted, and how access to the Customer Data would be controlled. Had FHG
12

made these enquiries and discovered the true state of affairs, they would have no
doubt required Agape to implement stricter controls to regulate Agents’ access and
use of the Customer Data. By failing to make such enquiries, FHG failed to appreciate
the reality of how Agape was storing, transmitting, and retaining the Customer Data,
and failed to exercise reasonable oversight over Agape’s data processing activities.

Unnecessary disclosure of sensitive personal data
32

Separately, FHG inadvertently disclosed personal data only intended for its

employees’ internal use, onto the SharePoint system shared with Agape. This included
sensitive financial information such as bank account numbers and bank codes, and
health information such as ICD codes and codes for surgical procedures done in
hospitals. These datasets were not required by Agape for the performance of the
Services, and this inadvertent disclosure ultimately led to a greater loss of personal
data during the Incident.

When an organisation discloses more personal data than is needed for its

purposes, this creates unnecessary data security risks, particularly where such data
is more sensitive in nature3.

Habitat for Humanity Singapore Ltd [2018] SGPDPC 9 (at [19]-[20])

In the Commission’s Guide to Data Protection Practices for ICT Systems4 (at

page 11), data minimisation has been encouraged as a good way for organisations to
examine what personal data is really needed. It should be a basic data protection
practice for organisations to collect, use, or disclose only the least sensitive types of
personal data if different types of personal data can be used to achieve the same
purpose.

FHG should have implemented robust measures to ensure that only personal

data necessary for performance of the Services was shared with Agape, and in
particular, that sensitive personal data was not inadvertently disclosed.

In view of the above, FHG was determined to have breached the Protection

Obligation in respect of the Customer Data.

Voluntary measures implemented by FHG and Agape
37

Following the Incident, FHG and Agape have voluntarily taken or will be taking

the following steps to prevent a recurrence of the Incident or similar events:

FHG
(a)

Agents will now access FHG’s customer data directly from FHG’s SharePoint

via individual user accounts with multi-factor authentication;

Published on 14 September 2021. The Guide compiles data protection practices from past Advisory
Guidelines, Guides and data breach cases that should be adopted by organisations in their ICT policies,
systems and processes.

(b)

FHG’s SharePoint has been reconfigured to grant “view-only” access to only

the specific files required by vendors for the services to be provided, with clear
segregation between the vendor’s SharePoint files and FHG’s internal SharePoint
files;
(c)

FHG will formally communicate its internal personal data protection policies and

processes to vendors in order for them to be applied to the vendors’ processing of
personal data on FHG’s behalf;
(d)

FHG will enhance its contracts with vendors to include additional data

protection obligations, such as the requirement for vendors to undergo regular
vulnerability assessments and penetration testing, rights for FHG to audit the vendor’s
data processing practices, and requirements for vendors to have in place reasonable
data breach response management processes;

Agape
(e)

With the assistance of external cybersecurity consultants, Agape has refreshed

its data protection and IT policies; and
(f)

Agape has increased data protection awareness by requiring employees to go

through the assessment tools provided on the Commission’s website, enrolling
employees in Workforce Skills Qualifications PDPA courses for certification, and
regularly conducting internal communications to maintain cybersecurity vigilance.

The Commissioner’s Decision

In determining whether any directions should be imposed on FHG and Agape

under Section 48I of the PDPA, and/or whether they should be required to pay a
financial penalty under Section 48J of the PDPA, the factors listed at Section 48J(6)
of the PDPA and the following mitigating factors were taken into account:

Mitigating Factors
(a)

FHG and Agape were cooperative during the investigations;

(b)

FHG and Agape voluntarily admitted to their breaches of the Protection

Obligation under the Commission’s Expedited Decision Procedure; and
(c)

FHG and Agape took prompt remedial actions following discovery of the

Incident.

While Agape’s breaches of the Protection Obligation were more causally

proximate to the unauthorised access and disclosure of personal data in the Incident,
FHG’s inadvertent disclosure of financial and health related data resulted in the impact
of the Incident being amplified. As the data controller, FHG also bore the ultimate
responsibility to exercise due diligence and reasonable supervision over Agape. For
the purposes of assessing what amount of financial penalty would be proportionate
and effective as a deterrent, it was also taken into consideration that FHG’s annual
turnover based on its latest available audited accounts, was almost 50 times higher
than that of Agape’s.
16

Having carefully considered all the relevant circumstances, the Commissioner

hereby requires that:
(a)

FHG pay a financial penalty of $58,000; and

(b)

Agape pay a financial penalty of S$10,000;

within 30 days of the date of the relevant notices accompanying this decision, 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.

In quantifying the financial penalties imposed, no weight was placed on Agape’s

status as a social enterprise. The standard of security arrangements expected under
the Protection Obligation will depend on the volume and nature of personal data in the
organisation’s possession or control, regardless of whether the organisation is a forprofit business, a charity, or a social enterprise5.

In addition to the financial penalties imposed, FHG and Agape are also directed

to do the following:

See Singapore Red Cross Society [2020] SGPDPC 16 at [10]

FHG
(a)

Within 60 days from the date of this decision:
i.

Review processes and contractual obligations with Agape and existing
vendors processing personal data on behalf of FHG, to ensure that such
vendors have sufficiently robust data handling processes to protect
personal data in their possession and/or control;

ii.

Review existing internal processes to ensure that only personal data
necessary for fulfilling contractual obligations is disclosed to vendors via
secured channels and with reasonable access controls considering the
type and volume of personal data being disclosed; and

(b)

Notify the Commission within 14 days of the completion of the reviews above,

with an outline of their scope.

Agape
(c)

Within 60 days from the date of this decision:
i.

Ensure that the scope of its periodic security reviews and any security
audits include the protection of personal data handled in all of Agape’s
systems and processes;

ii.

Resolve and record in writing with FHG the data protection requirements
and job specifications for the processing of personal data on behalf of
FHG, including arrangements for the exercise of regular oversight by
FHG to verify that the requirements and specifications are being met;
and
18

(d)

Notify the Commission within 14 days of the completion of the reviews above,

with an outline of their scope.

YEONG ZEE KIN
DEPUTY COMMISSIONER
FOR COMMISSIONER FOR PERSONAL DATA PROTECTION

","Financial Penalty, Directions",1b0b43399e4f4f5d75c72d6a95a144b1fdefd199
6,6,1,952,"Directions were issued to Kingsforce Management Services to ensure the implementation of regular patching, updates and upgrades for all software and firmware supporting its website(s) and application through which personal data in its possession may be accessed.","[""Protection"", ""Directions"", ""Employment"", ""Protection"", ""Patching""]",2023-05-11,https://www.pdpc.gov.sg/-/media/Files/PDPC/PDF-Files/Commissions-Decisions/GD_KingsforceManagementServicesPteLtd_100323.pdf,Protection,Breach of the Protection Obligation by Kingsforce Management Services,https://www.pdpc.gov.sg/all-commissions-decisions/2023/05/breach-of-the-protection-obligation-by-kingsforce-management-services,2023-05-11,"PERSONAL DATA PROTECTION COMMISSION
[2023] SGPDPCS1

Case No. DP-2202-B9480

In the matter of an investigation under section 50(1) of the
Personal Data Protection Act 2012
And
Kingsforce Management Services Pte Ltd

SUMMARY OF THE DECISION

1. On 31 January 2022, the Personal Data Protection Commission (the
“Commission”) was notified by Kingsforce Management Services Pte Ltd (the
“Organisation”) of the sale on RaidForums, on or about 27 December 2021, of
data from its jobseeker database (the “Incident”).

2. The affected database held approximately 54,900 jobseeker datasets, comprising
name, address, email address, telephone number, date of birth, job qualifications,
last and expected salary, highest qualification and other data related to job
searches.

3. External cyber security investigators identified outdated website coding
technology, with critical vulnerabilities, as the cause of the Incident.

4. The Commission accepted the Organisation’s request for handling under the
Commission’s expedited breach decision procedure. The Organisation voluntarily
provided and unequivocally admitted to the facts set out in this decision, and to
breach of section 24 of the Personal Data Protection Act (“the PDPA”).

5. The Organisation admitted work had not been completed on the website at launch
owing to contractual disputes with the developer. The Organisation subsequently
engaged IT maintenance vendors in an effort to ensure the security of the website.
However, maintenance had been ad-hoc and limited to troubleshooting
functionality issues from bugs, glitches and/or when a page failed to load.

6. In breach of the Protection Obligation, the Organisation failed to provide sufficient
clarity and specifications to its vendors on how to protect its database and personal
data. In Re Civil Service Club, the Commission had pointed out that organisations
that engage IT vendors can provide clarity and emphasize the need for personal
data protection to their IT vendors by a) making it part of their contractual terms,
and b) reviewing the requirements specifications to ensure that personal data
protection is reflected in the design of the end-product.1 Further, post-execution of
the contract, an organization is also expected to exercise reasonable oversight
over its vendor during the course of the engagement to ensure that the vendor is
protecting the personal data by adhering to the stipulated requirements.2

1 Re Civil Service Club [2020] SGPDPC 15.
2 Re WTS Automotive Services Pte Ltd [2019] PDP Digest 317 at [16] and [17].

7. Another breach of the Protection Obligation by the Organisation was failure to
conduct reasonable periodic security reviews, including vulnerability scans, since
the launch of its website. The requirement for and scope of reasonable periodic
security reviews had long been established in the published decisions of the
Commission.3 The PDPC’s Guide to Data Protection Practices for ICT Systems
also emphasized the need to periodically conduct web application vulnerability
scanning and assessments, post deployment, as a basic practice to ensure
compliance with the Protection Obligation under the PDPA.4

8. The Organisation is therefore found to have breached the Protection Obligation
under section 24(a) of the PDPA.

9. In deciding the enforcement action in this case, the Commission considered the
Organisation’s efforts towards website security, cooperation throughout the
investigation, voluntary admission of breach of the Protection Obligation and the
prompt remediation taken. The last included immediate suspension of its website,
and the engagement of a new developer to develop a new and enhance web
application. The Commission also notes that the affected personal data was no
longer or accessible following the shutdown of RaidForums. In the circumstances,
the Commission directs the Organisation to do the following:

a. To submit to the Commission, within twenty-one (21) days from the date of
issue of this Direction, a plan to ensure regular patching, updates and upgrades

3 See, eg, Re WTS Automotive Services Pte Ltd [2019] PDP Digest 317; Re Bud Cosmetics Pte Ltd

[2019] PDP Digest 351; and Re Watami Food Service Singapore Pte Ltd [2019] PDP Digest 221.
4 Pages 21 and 22 of the Guide to Data Protection Practices for ICT Systems.

for all software and firmware supporting its website(s) and applications through
which personal data in its possession may be accessed.

b. To state whether it intends to implement the plan by engagement of qualified
external services or by relying on its own resources, and if by engagement of
qualified external services, to state in detail the job specifications for software
and firmware patching, updates, and upgrades to be stipulated to the vendor.

c. To outline each implementation step with deadlines to ensure that the entire
implementation is completed within sixty (60) days from the date of issue of this
Direction.

The following is the provision of the Personal Data Protection Act 2012 cited in the
above summary:
Protection of personal data
24. An organisation shall protect personal data in is possession or under its control
by making reasonable security arrangements to prevent(a) unauthorized access, collection, use, disclosure, copying, modification or
disposal, or similar risks; and
(b) the loss of any storage medium or device on which personal data is stored.

",Directions,55f101a661c1696120dbd78b07f569b7bba4c9db
7,7,1,952,"A financial penalty of $8,000 was imposed on Fortytwo for failing to put in place reasonable security arrangements to protect the personal data in its possession. Fortytwo was also issued directions to complete the upgrading of its website to a supported software version, including vulnerability assessment and penetration testing.","[""Protection"", ""Financial Penalty"", ""Directions"", ""Wholesale and Retail Trade"", ""Patching""]",2023-05-11,https://www.pdpc.gov.sg/-/media/Files/PDPC/PDF-Files/Commissions-Decisions/GD_FortyTwo070323.pdf,Protection,Breach of the Protection Obligation by Fortytwo,https://www.pdpc.gov.sg/all-commissions-decisions/2023/05/breach-of-the-protection-obligation-by-fortytwo,2023-05-11,"PERSONAL DATA PROTECTION COMMISSION
[2023 SGPDPCS 3]

Case No. DP-2112-B9354
In the matter of an investigation under section 50(1) of the
Personal Data Protection Act 2012
And
Fortytwo Pte. Ltd.

SUMMARY OF THE DECISION

On 24 December 2021, Fortytwo Pte. Ltd. (the “Organisation”), an online

furniture

store,

notified

the

Personal

Data

Protection

Commission

(the

“Commission”) of malicious code injections on its website which led to the capturing
of the email address and password of 6,241 individuals when they logged in to its
website (the “Incident”). The name, credit card number, expiry date and CVV/CVN
number of another 98 individuals’ were also affected.

The Organisation requested for the matter to be handled under the

Commission’s expedited breach decision procedure. This means that the Organisation
voluntarily provided and unequivocally admitted to the facts set out in this decision;
and admitted that it was in breach of section 24 of the Personal Data Protection Act
(the “PDPA”).

An issue that arose in this case is whether fictitious names or pseudonymous

personal particulars form part of the personal data under the possession or control of
the Organisation. The importance of this lies in how it may potentially reduce the size
of the dataset that was at risk. In their addendum to the Written Statement, the
Organisation stated that it does not verify the names provided by the users, and
suggested that the impact of the Incident might be more limited as some of the users’
names may be incomplete, fictitious or pseudonymous.

Section 2(1) of the PDPA defines “personal data” to be data, whether true or

not (emphasis added), about an individual who can be identified from that data; or
from that data and other information to which the organisation has or is likely to have
access. The PDPA caters for the situation where not every record of personal data
that is under the possession or control of an Organisation is verified. It takes a practical
approach, as the accuracy of personal data records will change with the passage of
time (e.g. information becomes outdated) or individuals may intentionally provide
inaccurate information (e.g. users hiding their age or using fictitious residential
addresses to bypass restriction of services by age or geolocation). What matters is
that the Organisation, having collected the information, takes steps to comply with their
obligations under the PDPA, such as to protect them and to ensure that they are used
in accordance with the purpose of their collection.

The situation is different when the organisation, as a data security or data

management measure, applies pseudonymisation or anonymisation techniques on
personal data that is in their possession or under their control. In such circumstances,
if the risk of reidentification is adequately addressed and managed, the resulting
dataset may be treated as anonymised. The key difference is the intention of the
2

organisation and its ability to direct and control the data processing activities required
to achieve the resultant anonymised dataset.1

In this case, the Organisation was collecting data from its customers. Their

customer database contained names, email addresses and additional details such as
their shipping address, billing address, and date of birth. It also contained credit card
details of 98 customers. Even if some customers had provided incomplete, fictitious or
pseudonymous personal particulars or payment details, the Organisation had
collected personal data. For the purpose of this investigations, it matters not that some
of these customers may have provided inaccurate information. The Organisation’s
obligations under the PDPA applies to the entire customer database.

The Organisation admitted that the Incident occurred because the threat actor

had successfully exploited vulnerabilities present in the Magento open-source version
1.9.x.x which the Organisation had employed for its online store. These vulnerabilities
were present because the Organisation failed to apply four Magento security patches
released on 28 Nov 2017, 25 June 2019, 8 October 2019 and 28 April 2020 by Adobe.

Compounding the above, support for Magento version 1 had ended on 30 June

2020. The Organisation admitted that it should have upgraded to Magento opensource version 2.0 after Adobe ended the support for Magento 1 on 30 June 2020.
The Organisation had planned to upgrade to Magento version 2 in early 2020, but its
plans were disrupted by the COVID-19 pandemic. Having said that, Adobe had
announced in November 2015 that it will end support for Magento 1.x in 36 months,

1 See Personal Data Protection Commission, Advisory Guidelines on the Personal Data Protection Act

for Selected Topics, at paras 3.5, 3.8 and 3.13.
3

i.e. by November 2018. In September 2018, Adobe then announced that it would
extend the support to 30 June 2020. Given the ample notice given by Adobe to the
Organisation of the need to upgrade the version of Magento Open Source which it was
using in order to continue receiving support and security patches from Adobe, it is
difficult to look past the Organisation’s prolonged failure to do the needful and perform
the necessary upgrades.

The Commission had consistently advised organisations on the importance of

applying software patches. In our Guide to Data Protection Practices for ICT Systems,
the Commission had highlighted that organisations should perform system patching
promptly to fix security vulnerabilities. If software patches are not updated as
recommended by the software provider, they may not contain the latest cybersecurity
updates and may compromise the organisation’s defence against cyber-attacks.

10.

We note that the Organisation had considered and evaluated the four patches

but decided to hold back on installing them. However, these four patches were
released by Adobe to address several high severity risk issues and critical bugs,
including the injection of malicious codes. The Organisation’s failure to patch had
increased the risks of a malicious code injection capable of capturing users’ personal
data.

11.

In light of the above, the Organisation is found to have breached the Protection

Obligation under section 24(a) of the PDPA.

12.

The Commission notes that after the Incident, the Organisation took prompt

remedial actions, including notifying affected individuals and various technical
measures to improve its security. The Organisation is also taking steps to upgrade to
Magento version 2.

13.

In deciding the appropriate outcome in this case, the Commission considered

the Organisation’s cooperation throughout the investigation, the voluntary admission
of breach of the Protection Obligation, and the prompt remedial actions taken.

14.

Following the issuance of the Commission’s preliminary decision, the

Organisation represented that it was unfair to state that was a prolonged failure to
perform the necessary upgrade. This is because there was a lead time of 6 months
before the end of support when it made the decision to upgrade, before the COVID19 pandemic disrupted its plans. The Organisation’s representation is not accepted
as, notwithstanding the disruptions caused by the pandemic, the Organisation had
been given ample notice of the impending end of support but took no action to perform
the necessary upgrade from November 2015 to early 2020.

15.

Having considered the circumstances set out above, the factors listed at section

48J(6) of the PDPA and the representations made by the Organisation, the Deputy
Commissioner for Personal Data Protection hereby finds the Organisation in breach
and directs the Organisation to pay a financial penalty of S$8,000 within 30 days from
the notice accompanying date of this decision, failing which interest at the rate
specified in the Rules of Court in respect of judgement debts shall accrue and be

payable on the outstanding amount of such financial penalty until the financial penalty
is paid in full.

16.

The Organisation is also directed to:
a.

Complete the upgrading of its website to a supported software version,
including vulnerability assessment and penetration testing, within 6
months of the direction.

Inform the Commission with 14 days of the completion of the above.

The following is the provision of the Personal Data Protection Act 2012 cited in the
above summary:
Protection of personal data
24. An organisation shall protect personal data in its possession or under its control
by making reasonable security arrangements to prevent –
(a) unauthorised access, collection, use, disclosure, copying, modification, disposal or
similar risks; and
(b) the loss of any storage medium or device on which personal data is stored.

","Financial Penalty, Directions",94a50b28e4364bbb6e7cc57412b04d7d6841f870
8,8,1,952,"Directions were issued to The Law Society of Singapore to conduct a security audit of its technical and administrative arrangements for accounts with administrative privileges that can access directly and/or create access to personal data, and to rectify any gaps identified. This is pursuant to a data breach incident where The Law Society’s servers were subjected to a ransomware attack.","[""Protection"", ""Directions"", ""Professional"", ""Scientific and Technical"", ""Ransomware"", ""Patching"", ""Security"", ""Password""]",2023-05-11,https://www.pdpc.gov.sg/-/media/Files/PDPC/PDF-Files/Commissions-Decisions/GD_LawSocietyofSingapore_140323.pdf,Protection,Breach of the Protection Obligation by The Law Society of Singapore,https://www.pdpc.gov.sg/all-commissions-decisions/2023/05/breach-of-the-protection-obligation-by-the-law-society-of-singapore,2023-05-11,"PERSONAL DATA PROTECTION COMMISSION

[2023] SGPDPC 4

Case No. DP-2102-B7850

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

And

The Law Society of Singapore

… Organisation

DECISION

The Law Society of Singapore
Yeong Zee Kin, Deputy Commissioner — Case No. DP-2102-B7850
14 March 2023

Introduction
1

On 4 February 2021, the Law Society of Singapore (the “Organisation”)

notified the Personal Data Protection Commission (the “Commission”) of a
ransomware attack on its servers which had encrypted and denied the Organisation
access to the personal data of its members and former members (the “Incident”). The
Commission commenced investigations to determine whether the circumstances
behind the Incident disclosed any breaches by the Organisation of the Personal Data
Protection Act 2012 (“PDPA”).

Facts of the Case
2

The Organisation is a body corporate established under the Legal Profession

Act 1966 and represents members of the legal profession in Singapore. Every
advocate and solicitor called to the Singapore bar is a statutory member of the
Organisation as long as they have a practising certificate in force. At the material time,
the Organisation stored the personal data of its current and former members
(“Members”) in one of its servers for the purposes of carrying out its statutory
functions.

The Organisation had implemented an off-the-shelf secure VPN solution,

FortiOS, to manage remote access to its servers (the “VPN System”). The
Organisation also engaged a vendor (the “Vendor”) to provide IT support services,
including maintenance of the VPN System. For completeness, the Vendor was not the
Organisation’s data intermediary as it did not access or process the personal data of
the Members in the course of carrying out its IT support services.

The Organisation also implemented antivirus / malware detection software at

the servers, and password complexity requirements for its users’ accounts. In
particular, account passwords had a maximum lifespan of 3 months before a
compulsory change was required.

Additionally, the Organisation had in place a written data protection policy and

conducted data protection training for its staff highlighting cybersecurity threats such
as phishing and ransomware. Periodic emails on data protection awareness and
reminders were also sent to staff.

The Incident
6

On 27 January 2021, a threat actor gained access to the account of the

Organisation’s IT administrator (“compromised admin account”) and used this to
create a new account with full administrative privileges. Using this new account, the
threat actor moved through the Organisation’s network without detection and located
the Organisation’s servers. The threat actor then executed a ransomware attack on
the servers, encrypting their contents.

A total of 16,009 Members’ personal data was affected in the Incident, including

each Member’s full name, residential address, date of birth, and NRIC number. Other
data items were also affected but they are either in the nature of business contact
information or publicly available information.

The attack was detected on the same day by antivirus / malware detection

software deployed by the Organisation. The Organisation took immediate steps to
remove the new administrator account created by the threat actor and restored the
servers to their original state from secured back-ups.

Remedial actions
9

Following the Incident, the Organisation also took the following remedial

actions:
(a)

Removed unused administrator accounts and initiated password resets for
all administrator accounts;

(b)

Reduced privileged access for the compromised admin account (to create
new administrator accounts);

(c)

Hired an in-house cybersecurity professional to take charge of the
Organisation’s IT security matters;

(d)

Implemented multi-factor authentication (“MFA”) for all VPN access; and

(e)

Implemented VPN IP location whitelisting to allow only Singapore-based IP
addresses.

Findings and Basis for Determination

The Commission’s investigation centred on whether the Organisation had

breached its obligation under Section 24 of the PDPA 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 “Protection Obligation”). As the Vendor was not the
Organisation’s data intermediary, the Protection Obligation in this case was borne
solely by the Organisation.

Findings from the investigations
11

Investigations disclosed that there could have been multiple threat actors

targeting the Organisation or the same group of threat actors targeting the
Organisation through multiple channels – through brute force attacks, phishing email,
and exploiting the unpatched VPN vulnerability of the VPN System.

Brute-force attacks. Around ten days before the Incident, multiple

unsuccessful login attempts using a “guest” account were found since 18 January
2021. There were also further unsuccessful attempts made using random accounts.
However, investigations did not surface evidence that the initial entry by the threat
actor had been via a successful brute force attack on the compromised admin account.

Phishing emails. Investigations also revealed that the Organisation was

attacked by the Netwalker ransomware, most commonly introduced via phishing
emails. From the Vendor’s explanations, the administrator of the compromised admin
account could have received a phishing email with a link and entered his credentials.
However, investigations did not surface evidence of any phishing email relevant to this
5

ransomware; neither was there evidence that the compromised admin account’s
credentials was obtained by a threat actor through phishing.

Vulnerability of the VPN System. At the material time before the Incident,

MFA was not implemented for the Organisation’s administrator access to its servers.
This meant that once authenticated, an admin user had rights to create new accounts,
assign privileged security groups, and access all of the Organisation’s servers without
the need for a second factor.

Investigations revealed that there was a vulnerability in the VPN System which

could be exploited to gain access credentials if left unpatched (the “Vulnerability”).
This was assessed to be a possible way in which the threat actor obtained the
credentials of the compromised admin account:
(a)

Around November 2020, a file containing more than 45,000 session links
and IP addresses for the VPN System of affected organisations (including
the Organisation) was found posted in online forums by someone who had
obtained the information by exploiting the Vulnerability.

(b)

Without patching the VPN System’s firmware, each session link would
disclose the credentials of users in plain text, including passwords.

(c)

The date/time of the online publication (i.e. November 2020) was sufficiently
proximate to the threat actor’s successful intrusion in January 2021 using
the compromised admin account.

From the foregoing, it would appear that of the three possible attack vectors,

the vulnerability in the VPN System could have given the threat actor entry into the
Organisation’s environment.

No breach of the Protection Obligation for omission to patch the Vulnerability
17

The developer of the VPN System, Fortinet, had disclosed the Vulnerability as

early as 24 May 2019. It released an Operating System (“OS”) upgrade to remedy the
issue, which contained the updates to remedy the issue. The VPN System had a user
interface (“UI”) through which the OS upgrade availability could be notified. According
to the Vendor, the Vendor had regularly checked the UI if OS upgrades were available
but there were no prompts of updates available for download prior to the Incident.
According to the Organisation, it was only after it communicated the issue to the
developer, after the incident, that the UI subsequently prompted availability of some
patches that included the OS upgrade remedying the Vulnerability.

The Commission recognises that organisations may rely on vendors engaged

to provide IT security maintenance to obtain and apply needed software upgrades and
patches. If so, the Protection Obligation requires organisations to stipulate such
requirements clearly in writing as part of the job specifications of such vendors. In this
case, patching of the VPN System had been a specific obligation explicitly outsourced
by the Organisation to the Vendor via contract.

In addition to clearly stipulating the vendor’s scope of IT maintenance and/or

development work, organisations are expected to exercise reasonable oversight over
the vendor’s performance of the subcontracted services, including patching – Re
7

Smiling Orchard (S) Pte Ltd and Ors [2016] SGPDPC 191. There should be a clear
meeting of minds as to the services the service provider has agreed to undertake and
organisations must follow through with procedures to check that the outsourced
provider is delivering the services.

The Commission appreciates that the technical nature of information on

software patching and upgrades limits the degree of oversight that many organisations
can exercise on vendor performance in this regard. The Commission notes that the
Organisation had put in place a process to ensure that there were maintenance logs
in respect of the Vendor’s activities. Thus, the Organisation, to its credit, had put in
place a system to monitor its Vendor’s activities. In technical areas where the
Organisation depends on its Vendor’s technical expertise, this is reasonably adequate.
The situation may be different if there was a very well-publicised issue with a wellknown commercial solution (e.g. vulnerabilities affecting a network router) that the
Organisation ought to know that it uses. In such situations, the Organisation might be
at least expected to query its Vendor about whether it is exposed and ask for a
remediation plan. But this is probably limited to well-known and well-publicised issues
in mass media.

Carefully weighing the above circumstances, the Commission has decided that:

(a) it had been reasonable for the Organisation to rely on the Vendor to perform
software security patching, including of the Vulnerability, and (b) that the Organisation

See also Singapore Health Services Pte. Ltd and Integrated Health Information Systems Pte Ltd [2019] SGPDPC
3.
8

had in this case discharged its duty of oversight of the Vendor’s patching function.
Therefore the Organisation has not breached the Protection Obligation.

Breach of the Protection Obligation by the Organisation in other aspects
22

Investigations revealed that the password for the compromised admin account

was “Welcome2020lawsoc”. Despite this password complying with the Organisation’s
own password complexity rules, the Organisation acknowledged that this was a weak
password and vulnerable to dictionary attacks due to the use of a full word and the
Organisation’s name. As highlighted in Chizzle Pte Ltd [2020] SGPDPCR 1, a
password that meets complexity rules in form could still be regarded as a weak
password if it was easily determined and vulnerable to brute force attacks. In that case,
the password “Chi!zzle@2018” incorporated the organisation’s name and was
determined to be a weak password. Further, the Organisation informed that the
compromised admin account’s password had been used for more than 90 days and
had not been changed every 3 months, as required by the Organisation’s password
policy. In the circumstances, the Organisation failed to enforce its password policy in
relation to the compromised admin account.

In the Commission’s recent Guide to Data Protection Practices for ICT

systems2, it has been observed that unauthorised access is one of the most common
types of data breaches. This can happen, for example, through the use of a weak
password which is easily guessed by hackers. To remediate this, it may be practical
to look into implementing processes in ICT systems to minimise risk of brute force

Published on 14 September 2021, replacing the Guide to Data Protection by Design for ICT systems published
on 31 May 2019, after the Incident.
9

attacks (e.g. a pre-defined number of failed login attempts) and ensure information is
accessed only by the authorised/authenticated persons performing the intended
activities. Additionally, as 2FA or MFA becomes more broadly available, the adoption
of these tools should become the norm for accounts with administrative privileges, for
systems managing sensitive data or large volumes of personal data3.

Next, the Organisation also did not conduct a review of its security

arrangements within the last 3 years prior to the Incident. Regular assurance checks
help organisations ensure that ICT security controls developed and configured for the
protection of personal data are properly implemented and practised4. In Re WTS
Automotive Services Pte Ltd [2018] SGPDPC 265, the Commission emphasised (at
[18]) for the need for regular review of security arrangements and tests to detect
vulnerabilities.

For the above reasons, the Organisation is found to have negligently breached

the Protection Obligation by (i) using an easily guessable password for the
compromised admin account, (ii) failing to change the password for the compromised
admin account at reasonable intervals, and (iii) failing to conduct any periodic security
reviews in the three years leading up to the Incident.

See the Commission’s recent release of the handbook on common causes of data breaches in How to Guard
against Common Types of Data Breaches published on 24 May 2021 (at page 13), after the Incident; See Love
Bonito Singapore Pte Ltd [2022] SGPDPC 3.
4
See the Guide to Data Protection Practices for ICT systems.
5
See also Jigyasa [2020] SGPDPC 9.
10

The Deputy Commissioner’s Decision
26

Notwithstanding that the Organisation’s breaches of the Protection Obligation

were not directly related to the Incident, the Commission’s role is not limited to
investigating only the immediate or proximate causes of a data breach incident 6. In
determining whether directions (if any) should be given to the Organisation pursuant
to Section 48I of the PDPA, and/or whether a financial penalty ought to be imposed
pursuant to Section 48J of the PDPA, the Deputy Commissioner took into
consideration the relevant facts and circumstances of the case, and in particular the
following factors:
(a)

The Organisation’s breaches of the Protection Obligation were not the most
proximate cause of the Incident (which was the VPN Vulnerability);

(b)

The datasets affected in the Incident were not of a higher sensitivity (e.g.
personal data of a financial or medical nature);

(c)

The risk of unauthorised access to the Members’ personal data was limited
due to early detection of the unauthorised access, which also allowed
prompt containment and restoration of the servers to its original state;

(d)

There was no evidence of any exfiltration or misuse of the personal data of
the Members; and

(e)

The Organisation took prompt remedial actions in response to the Incident.

For the above reasons, it is adequate for directions to be issued in this case.

The Deputy Commissioner hereby directs the Organisation to:
(a)

Engage qualified security service providers to conduct a thorough security
audit of its technical and administrative arrangements for the security,

See Love Bonito Singapore Pte Ltd [2022] SGPDPC 3.
11

maintenance, creation and removal of accounts with administrative
privileges that can access directly and/or create access to personal data in
the possession or control of the Organisation;
(b)

Furnish to the Commission within 14 days a schedule stating the scope of
the security audit;

(c)

Provide the full security audit report to the Commission, by no later than 60
days from the date of the issue of this direction;

(d)

Rectify any security gaps identified in the security audit report, review and
update its personal data protection policies as applicable, and

(e)

Inform the Commission within 1 week of completion of rectification and
implementation in response to the security audit report.

YEONG ZEE KIN
DEPUTY COMMISSIONER
FOR PERSONAL DATA PROTECTION

",Directions,7d6096f9562cfde74f556a2117cc264960050a02
9,9,1,952,"A financial penalty of $37,000 was imposed on OrangeTee & Tie for failing to put in place reasonable security arrangements to protect users' personal data in its possession or under its control.","[""Protection"", ""Financial Penalty"", ""Real Estate""]",2023-04-17,https://www.pdpc.gov.sg/-/media/Files/PDPC/PDF-Files/Commissions-Decisions/GD_OrangeTee_210223.pdf,Protection,Breach of the Protection Obligation by OrangeTee & Tie,https://www.pdpc.gov.sg/all-commissions-decisions/2023/04/breach-of-the-protection-obligation-by-orangetee-and-tie,2023-04-17,"PERSONAL DATA PROTECTION COMMISSION

[2023] SGPDPC 3

Case No. DP-2108-B8712

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

And

OrangeTee & Tie Pte Ltd
… Organisation

DECISION

OrangeTee & Tie Pte Ltd
Lew Chuen Hong, Commissioner — Case No. DP-2108-B8712
21 February 2023

Introduction

On 4 August 2021, the Personal Data Protection Commission (“Commission”)

contacted OrangeTee & Tie Pte Ltd (“Organisation”) after receiving information
indicating that a threat actor had managed to exfiltrate databases in the Organisation’s
possession, which were believed to contain personal data.

Subsequently, on 6 August 2021, the Organisation notified the Commission of

an incident involving unauthorised access to its IT network (the “Incident”). The
Organisation also gave a media statement on the same day informing members of the
public about the Incident and inviting any concerned customers to contact the
Organisation’s call centre for clarification.

The

Commission

then

commenced

investigations

determine

the

Organisation’s compliance with the Personal Data Protection Act 2012 (“PDPA”) in
relation to the Incident.

Facts of the Case

The Organisation is a real estate enterprise based in Singapore and has been

in operation since 2000.

Four servers maintained by the Organisation were involved in the Incident,

namely: the Production Web Server, the Production Database Server, the
Development Web Server, and the Development Database Server. The Production
Web Server and the Development Web Server (collectively the “Web Servers”) were
internet-facing, in that they were directly accessible from the internet. The Production
Web Server was linked to the Production Database Server, while the Development
Web Server was linked to the Development Database Server.

The personal data of employees and customers of the Organisation was stored

on the Production Database Server and the Development Database Server
(collectively the “Database Servers”). The personal data had not been encrypted.

The Databases Servers were running Microsoft SQL Server 2012 Standard

version 11.0.6251.0 (Service Pack 3) at the time of the Incident, which Microsoft had
ceased support for on 9 October 2018. Additionally, the version of Microsoft SQL
Server the Organisation used was also not updated, as the most current Service Pack
4 was not installed.

The Incident

On 3 August 2021, the Organisation received a ransom demand email from an

organisation which identified themselves as ‘ALTDOS’. The email was sent from an
email address which is known to be used by the ALTDOS group. The threat actor
claimed that they had been hacking the Organisation’s network since June 2021 and

had stolen “hundreds of databases”, some of which were claimed to contain sensitive
information. The ransom demand also contained video footage of five databases
purported to have been stolen, which showed that sensitive data might have been
exfiltrated from the Organisation’s servers.

In the same email, the threat actor demanded a ransom of 10 Bitcoins for the

safety and non-disclosure of the exfiltrated databases and threatened disclosure if the
ransom was not paid. The Organisation filed a police report and reported the Incident
to the Singapore Computer Emergency Response Team, a division of the Cyber
Security Agency of Singapore.

On 4 August 2021, having not received the demanded ransom, ALTDOS

carried out a Distributed Denial-of-Service attack which brought down the
Organisation’s network, and sent an additional ransom demand via email and
WhatsApp to some of the Organisation’s employees.

The Organisation engaged a private forensic expert (“PFE”) to ascertain the

cause and extent of the Incident. PFE’s investigations disclosed that, contrary to their
claims, the threat actor exfiltrated personal datasets from eleven databases,
containing personal data set out in the table below:

Category of

Number of

Individuals

Employees

305

Types of Personal Data Affected

Name, full NRIC/FIN/passport number and bank account
number

Customers

245,752

Name, full NRIC/FIN/passport number and property
transaction amount

Agents

10,526

1. Name, full NRIC/FIN/passport number and bank
account number (2,301 individuals)

2. Name, full NRIC/FIN number, bank account number
and commission amount (4,763 individuals)

3. Name, full NRIC/FIN number, commission amount
(286 individuals)

4. Name, full NRIC/FIN number (3,176 individuals)
TOTAL

256,583

The PFE’s investigations found that the threat actor had carried out certain web-

based attacks and exploited vulnerabilities on the Web Servers to successfully
exfiltrate databases from the outdated Database Servers. The following observations
were made by the PFE:
(a)

Production Web Server – the PFE concluded that the threat actor used

SQL injection attacks on the Production Web Server. SQL injections are a way
of exploiting vulnerable website code and forms to return data from a SQL
database that should not be available to a user. The PFE also found that the
threat actor had likely used a malicious tool known as ‘SQL Map’ on vulnerable
webpages in the Production Web Server, to automate the systematic probing of
webpages for SQL injection vulnerabilities. Once the vulnerabilities were
discovered, the threat actor then proceeded to exploit the vulnerabilities to
access and exfiltrate data from four databases within the Production Database
Server at some point(s) between 24 June 2021 and 3 August 2021.

(b)

Development Web Server – the PFE could not locate forensic artefacts

to confirm the mode of attack by the threat actor. However, the PFE identified

evidence of cross-site scripting attacks. Cross-site scripting attacks involve the
injection of malicious scripts into trusted websites which are then executed on
end-users’ browsers. In this case, malicious code had been injected into the
Development Web Server. This led the PFE to believe that the Development
Web Server was compromised. The threat actor is believed to have exploited the
compromised Development Web Server to access and exfiltrate data from seven
databases on the Development Database Server, although it was unclear how
and when this had occurred.

Remedial actions

Following the Incident, the Organisation implemented the following remedial

measures:

Immediate remedial steps to contain the Incident

(a)

Shut down and isolated the affected servers from the rest of the IT network;

(b)

Updated its servers with the latest security patches;

To prevent recurrence or similar incidents

(c)

Tested the affected servers for vulnerabilities and deployed enterprisegrade anti-malware software across the IT network;

(d)

Carried out security hardening activities, including the removal of redundant
services, restricting access and services, and ensuring the server is secure
to ‘Center for Internet of Security’ (CIS) benchmarking standards;

(e)

Carried out detailed analysis of intrusion prevention logs;

(f)

Reviewed and secured the firewall configuration;

(g)

Separated the public-facing website from the internal agent portal and
ensured that the former was securely hosted;

(h)

Implemented a web application firewall to protect the network; and

(i)

Liaised with the PFE on the recovery process as well as improving IT
security.

Findings and Basis for Determination

Based on the circumstances of the Incident, the Commission’s investigation

centred on whether the Organisation had breached its obligation under section 24 of
the PDPA 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 “Protection
Obligation”). The Organisation was determined to have breached the Protection
Obligation in the following two respects.

Use of production data in Development Servers for testing purposes

First, the Organisation used ‘live’ production data for development and testing

purposes without sufficiently robust processes to protect the personal data through
proper safeguards.
16

The ‘live’ production data used included personal data and had been stored in

the development environment (i.e. the Development Servers) from which the datasets
had been exfiltrated by the threat actor. The Organisation explained the use of ‘live’
production data as being necessary in order for the testing computations to be
accurately derived, and for the actual business process flow to be effectively tested.

The Commission has advised in its Handbook on How to Guard Against

Common Types of Data Breaches (the “Handbook”) at page 11 that use of ‘live’
production personal data for testing creates a security risk. 1 The safer practice would
be to use anonymised data for testing purposes. Synthetic data, which is fake data
that contains similar characteristics as the real data, is a form of anonymised data.
Another way is to use pseudonymised data where direct identifiers have been replaced
with pseudonyms. The Commission has explained the rationale for anonymisation of
personal data for development and business study in the Advisory Guidelines on the
PDPA for Selected Topics:

Handbook on How to Guard Against Common Types of Data Breaches (“Handbook”), page 11: “Out of convenience, many
organisations use production data for system testing in their test environments. But as test environments tend to be much less
secured, there is a high risk of data breach in a test environment.” (https://www.pdpc.gov.sg/news-andevents/announcements/2021/05/handbook-on-how-to-guard-against-common-types-of-data-breaches-now-available)
1

“3.14 Anonymisation of personal data enables businesses to tap on data
for insights and innovation while at the same time provides protection to
individuals. It also reduces the impact of harm to individuals in the event of a
data breach. Where possible, Organisations should adopt such practices for
external sharing of data. It can even be adopted when sharing data internally,
particularly where individuals need not be identified for the purposes of
processing.

3.15 In the event of a data breach, the level of data anonymisation,
corresponding

safeguards

implemented

and

proper

assessment

organisations in considering the harms of the anonymised data would be taken
into consideration to assess if data has been properly anonymised.”2
(emphasis in bold added)

The Commission’s position on this issue had been reiterated in Re PINC

Interactive Pte Ltd [2022] SGPDPC 1, in which it was held that the organisation had
breached the Protection Obligation by using a synthetic dataset that contained
personal data belonging to real users. It should have used 100% synthetic data.3

However, where the use of ‘live’ personal data is operationally necessary,

sufficiently robust processes should be implemented to safeguard the personal data.
Testing or development environments are usually not as secured as production
environments. The Organisation in this case had failed to implement sufficiently robust

Advisory Guidelines on the PDPA for Selected Topics, page 14, paragraphs 3.14 – 3.15 (https://www.pdpc.gov.sg/guidelinesand-consultation/2020/02/advisory-guidelines-on-the-personal-data-protection-act-for-selected-topics)
3
Re PINC Interactive Pte Ltd [2022] SGPDPC 1, [10] – [12]
2

processes in the form of a security assessment of the risk from using, and storing,
‘live’ personal data in a testing environment. Such a security assessment could
consider, for example, whether to restrict access to a smaller group of testers and limit
the duration when live data is loaded in the testing environment. If the testing
environment is accessible from the Internet, security assessment ought to also be
carried out of the risk of unauthorised web entry.

Without such an assessment, the Organisation was not positioned to make an

informed decision on whether the security arrangements to protect the personal data
had been reasonable or had needed to be enhanced. The lack of sufficiently robust
processes to protect personal data through proper safeguards, such as the conduct of
a reasonable security assessment, amounted to a breach of the Protection Obligation
by the Organisation.

Failure to conduct reasonable periodic security reviews prior to the Incident

Second, the Organisation failed to conduct reasonable periodic security

reviews for its servers.

The Commission’s previous decisions4 and the Guide5 have established that

periodic security reviews should be conducted to a reasonable standard to identify and
remedy any vulnerabilities. Such scheduled reviews should be in place as a basic
practice as it would likely have resulted in the detection of the vulnerabilities arising
from the outdated software and the risk of SQL injection techniques. The Organisation

4
5

WTS Automotive Services Pte. Ltd. [2018] SGPDPC 26 and Commeasure Pte Ltd [2021] SGPDPC 11
Guide, page 21, paragraph (g)

admitted in its submissions to the Commission that it had not considered the need for
such security reviews in its IT security policy.

Both Web Servers were internet-facing and were connected to production data

stored in both Database Servers, thereby exposing the ‘live’ production data contained
therein (containing personal data) to security risks. However, owing to its failure to
conduct periodic security reviews for the Web and Database Servers, the Organisation
did not recognise the risks engendered by the outdated software and did not take steps
to assure itself that all internet-facing servers were adequately protected. Had the
Organisation conducted reasonable periodic security reviews prior to the Incident, the
vulnerabilities to SQL injection techniques in the Web Servers would have been known
and remedied. The Incident could then very likely have been avoided.

For the above reasons, the Organisation was determined to have breached the

Protection Obligation by (i) using personal data belonging to real users in a
development environment (i.e. the Development Servers) without a sufficiently robust
process for a reasonable security assessment of the risk, and (ii) failing to conduct
reasonable security reviews prior to the Incident.

Organisation’s position on the failure to update Microsoft SQL Server 2012

The Organisation explained its failure to update the Database Servers’

Microsoft SQL Server 2012 version and install Service Pack 4 as follows:
(a)

The Organisation’s IT team relied on Microsoft’s own auto-scan function

to be alerted to available updating patches as a prompt for installation. This

Microsoft tool ran once a month before the Incident. The tool, however, failed to
detect that the installed version of Microsoft SQL Server 2012 in the servers
required patching, and that the required patch in the form of Service Pack 4 had
been available.

(b)

The tool had not previously failed to detect and alert about required

updates.

(c)

The alternative option of requiring the IT team to conduct a manual

review of all updates released by Microsoft every month had not been practical
or reasonable as compared to relying on the auto-scan function.

(d)

The Organisation’s IT team did not use third-party scanning software to

monitor and detect available patches because even these might not have
identified the need to patch Microsoft SQL Server 2012 with Service Pack 4.

The Commission’s investigation revealed no known issues relating to the

availability or installation of Microsoft SQL Server 2012 Service Pack 4 updates. The
Protection Obligation required the Organisation to have sufficiently robust processes
to protect personal data through regular patching / updates / upgrades of important
software. The question is whether the Organisation’s reliance on system prompts in
the form of alerts from the Microsoft auto-scan function had amounted to a sufficiently
robust process for patching in the circumstances of this case.

Service Packs are significant collations of updates and patches that have been

released. When released, Service Packs effectively provide a new baseline of updates
and patches. On the question above, the Commission noted that the Microsoft
Knowledge Base site indicated that the Service Pack 4 update had been available
through the usual Windows Update auto-scan function since October 2017. This
means that it would have been available for almost 4 years at the time of the Incident.
Considering that an important software patch in the form of the Service Pack 4 had in
this case been available for almost 4 years, the Organisation’s reliance on system
prompts such as alerts through the auto-scan function had not been a sufficiently
robust process to patch important software for the security of personal data. The
Organisation should be aware of significant Service Packs and consciously decide
whether to upgrade.

The Commissioner’s Decision

In determining whether to impose a financial penalty on the Organisation

pursuant to section 48J(1) of the PDPA, and the amount of any such financial penalty,
the matters set out at section 48J(1), and the factors listed at section 48J(6) of the
PDPA were taken into account, including the following mitigating factors:

Mitigating Factors

(a)

The Organisation took prompt remedial actions, including notifying the
affected individuals;

(b)

The Organisation was cooperative during investigations; and

(c)

The Organisation voluntarily admitted that it had breached the Protection
Obligation in Section 24(a) of the PDPA in failing to protect personal data
in its possession by making reasonable security arrangements to prevent
unauthorised access.

The Commission further notes that names and property transaction amounts

were among the categories of personal data which was exfiltrated. Whilst the
Commission took the exfiltration of such personal data into account in its decision, it
does not consider these categories to be highly sensitive in nature as this information
is, to a certain extent, already in the public domain. For example, a member of the
public is able to look up such information through a land titles search on the Singapore
Land Authority website (for names), or a search on the Urban Redevelopment
Authority website for caveats lodged (for property transaction amounts). Thus, this
information is publicly available as defined in s 2(1) of the PDPA.

Having considered all the relevant circumstances of this case, the

Commissioner hereby requires the Organisation to pay a financial penalty of $37,000
within 30 days from the date of the relevant notice accompanying this decision, 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.

No further directions are necessary on account of the remedial measures

already taken by the Organisation.

YEONG ZEE KIN
DEPUTY COMMISSIONER
FOR COMMISSIONER FOR PERSONAL DATA PROTECTION

",Financial Penalty,bc2f44656c288eb64e8e9ad0568ae8dadb65e251
10,10,1,952,"A warning was issued to an individual for using dictionary attack methods to generate telephone numbers which were then used for telemarketing purposes, thereby breaching section 48B of the PDPA.","[""Do Not Call Provision(s)"", ""Warning"", ""Others"", ""Telemarketing""]",2023-04-17,https://www.pdpc.gov.sg/-/media/Files/PDPC/PDF-Files/Commissions-Decisions/GD_TaiShinFatt_140223.pdf,Do Not Call Provision&#40;s&#41;,Breach of Section 48B of the PDPA (Prohibition on Use of Dictionary Attacks) by an individual,https://www.pdpc.gov.sg/all-commissions-decisions/2023/04/breach-of-section-48b-of-the-pdpa-prohibition-on-use-of-dictionary-attacks-by-an-individual,2023-04-17,"PERSONAL DATA PROTECTION COMMISSION

[2023] SGPDPC 2

Case No. ENF-DNC-210826-0015

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

And

Tai Shin Fatt
… Individual

DECISION

Tai Shin Fatt
Lee Ti-Ting, Assistant Commissioner - Case No. ENF-DNC-210826-0015

14 February 2023

Introduction
1

On 2 July 2021, the Personal Data Protection Commission (“the Commission”)

was notified by the Singapore Police Force that the Singapore Civil Defence Force
(“SCDF”) had received an influx of marketing calls between 25 and 28 June 2021 from
telephone numbers registered to one LongSheng Consultancy Pte Ltd (“LongSheng”)
on behalf of one Tai Shin Fatt (the “Individual”). The Commission commenced
investigations to determine whether the circumstances relating to the calls disclosed
any breaches of the Personal Data Protection Act 2012 (“PDPA”).

Facts of the Case
2

The Individual is an insurance director with a large and well-known insurance

company managing a team of 25 insurance agents. In an effort to conduct marketing
calls more efficiently, the Individual sought to engage the services of 2 companies
hereinafter referred to as the “Call Automation Vendor” and the “Checker”.

The Call Automation Vendor provides software to facilitate the making of

automated calls using customised scripts. The Checker’s service comprises the
provision of telephone numbers (from which automated calls could be made), and the
provision of software to check whether the telephone numbers of intended recipients

were registered with the Do Not Call Registry (“DNCR”). The systems / software of the
Call Automation Vendor and the Checker were intended to work in tandem as follows:

(a)

the telephone numbers of intended recipients would be uploaded onto the Call
Automation Vendor’s software;

(b)

the Checker’s software would check the DNCR for such telephone numbers;
and

(c)

the Call Automation Vendor’s software would then avoid making any calls to the
telephone numbers which appeared in the DNCR.

As the Call Automation Vendor and the Checker do not contract directly with

individuals, the Individual caused LongSheng to enter into contracts with the Call
Automation Vendor and the Checker on 17 March 2021 and 20 May 2021 respectively,
to provide the services outlined at paragraph 3 above. The Individual used LongSheng
as a corporate vehicle by which to procure the services of the Call Automation Vendor
and the Checker.

Following the engagement of the Call Automation Vendor and the Checker, and

pursuant to instructions from the Individual, the Call Automation Vendor provided 10
channels in its software, while the Checker subscribed for 10 telephone numbers in
the name of LongSheng from which to make the automated marketing calls.

The Individual wished to test the systems provided by the Call Automation

Vendor and the Checker, for which recipient telephone numbers were required. One
of the Individual’s staff suggested to generate recipient telephone numbers by:

(a)

using commonly seen telephone numbers for the first 4 digits of each telephone
number; and

(b)

randomly generating the last 4 digits of the telephone number by automated
means.

The Individual authorised this method of generating the telephone numbers,

and his staff proceeded to use Microsoft Excel to do so.

The Individual’s staff generated a total of 18,809 telephone number (“Subject

Numbers”), which included 400 telephone numbers beginning with the digits “995”.
“995” is the SCDF emergency line.

The Subject Numbers were contained in 3 lists, which were uploaded onto the

Call Automation Vendor’s software by a member of the Individual’s staff. The Individual
then clicked “send/call” in the Call Automation Vendor’s software to commence the
automated marketing calls.

Between 25 and 28 June 2021, a total of 22,268 automated marketing calls

were made (the “Subject Calls”), of which 433 were to the SCDF emergency line (the
“Incident”). Such calls were not blocked as the SCDF emergency line was not
registered in the DNCR.

On 28 June 2021, while reviewing the call recordings, the Individual discovered

the calls made to the SCDF emergency line and immediately instructed his staff to
stop using the Call Automation Vendor’s software. He also contacted the Call

Automation Vendor to stop making further automated marketing calls; and deleted the
lists containing the Subject Numbers.

Findings and Basis for Determination
The prohibition under Section 48B of the PDPA
12

Based on the circumstances of the Incident as set out above, the Commission’s

investigation focused on whether the Individual had breached section 48B(1) of the
PDPA by sending, causing to be sent, or authorising the sending of “applicable
messages” - namely, (i) messages with a Singapore link to (ii) telephone numbers
generated by a dictionary attack or address harvesting software (""Section 48B
Prohibition"").

The Section 48B Prohibition and other provisions of the PDPA setting out

relevant definitions are reproduced below:
Term and definition
(…) a person must not send, cause to be sent or

PDPA provision
s48B(1)

authorise the sending of an applicable message.
“applicable message” means a message with a

s48A(1)

Singapore link that is sent to any applicable telephone
number;
“message” means any message, whether in sound, text,

s36(1)

visual or other form;
(2) In this Part, an applicable message has a Singapore
link in any of the following circumstances:

s48A(2)

(a)

the message originates in Singapore;

(b)

the sender of the message —
(i)

where the sender is an individual — is

physically

present

Singapore

when

the

message is sent; or
(ii)

in any other case —
(A)

is formed or recognised under the

law of Singapore; or
(B)

has an office or a place of business

in Singapore;
(c)

the telephone, mobile telephone or other device

that is used to access the message is located in
Singapore;
(d)

the recipient of the message —
(i)

where the recipient is an individual — is

physically

present

Singapore

when

the

message is accessed; or
(ii)

in any other case — carries on business or

activities in Singapore when the message is
accessed;
(e)

if the message cannot be delivered because the

telephone number to which the message is sent has
ceased to exist (assuming that the telephone number
existed), it is reasonably likely that the message would

have been accessed using a telephone, mobile
telephone or other device located in Singapore.
“applicable telephone number” means a telephone

s48A(1)

number that is generated or obtained through the use of
—
(a)

a dictionary attack; or

(b)

address‑harvesting software;

“dictionary attack” means the method by which the

s48A(1)

telephone number of a recipient is obtained using an
automated means that generates possible telephone
numbers

combining

numbers

into

numerous

permutations;
“address‑harvesting software” means software that is

s48A(1)

specifically designed or marketed for use for —
(a)

searching the Internet for telephone numbers; and

(b)

collecting, compiling, capturing or otherwise

harvesting those telephone numbers

The Section 48B Prohibition was introduced as part of the 2020 amendments

to the PDPA and came into effect on 1 February 2021. It was intended to supplement
the existing “Do Not Call” provisions in Part 9 of the PDPA in striking the correct
balance between safeguarding consumer interest and permitting legitimate business
interests in direct marketing by:

(a)

establishing clear guardrails for sending unsolicited commercial messages; 1
and

(b)

addressing consumer annoyance and deterring spammers who use
technologies that make it easier to indiscriminately send unsolicited commercial
messages (including robocalls) to a large number of recipients.2

The Section 48B Prohibition operates by targeting the indiscriminate manner

by which recipient telephone numbers may be generated and targeted, usually by
automated means. It does not serve as a blanket prohibition on the sending of
unsolicited commercial messages, and leaves room for legitimate direct marketing.

Whether the Individual had contravened the s48B Prohibition
16

For the Individual to have breached the Section 48B Prohibition, he must have:

(a)

sent, cause to be sent or authorized the sending of;

(b)

a message;

(c)

with a Singapore link;

(d)

to telephone numbers generated or obtained through use of:

(i)

a dictionary attack; or

(ii)

address harvesting software.

Based on the facts of the Incident as set out above, the elements for breach of

the Section 48B Prohibition are made out:

Singapore Parliamentary Debates (2 November 2020) vol 95, at page 36 (S Iswaran, Minister for Communications and
Information)
2 Public Consultation Paper issued by the Ministry of Communications and Information and the Personal Data Protection
Commission dated 14 May 2020, at paragraphs 53 54(b)

(a)

The Individual specifically authorised and caused the making of the Subject
Calls to the Subject Numbers.

(b)

The Subject Calls were automated calls based on a customised script provided
by the Call Automation Vendor. The Subject Calls were therefore messages in
sound form, and “messages” as defined by s36(1) of the PDPA.

(c)

The Subject Calls were made in Singapore. As such, the Subject Calls had a
“Singapore link” within the meaning of s48A(2) of the PDPA.

(d)

The Subject Numbers were generated by using commonly seen telephone
numbers for the first 4 digits, then randomising the remaining 4 digits. Strings
of numbers were combined and resulted in the creation of 18,809 different
permutations – i.e. unique telephone numbers – and the process was
performed using automated means via Microsoft Excel. This was therefore a
“dictionary attack” within the meaning of s48A(1) of the PDPA.

Accordingly, the Individual is determined to have contravened the Section 48B

Prohibition.

The Commission’s Decision

By using a “dictionary attack” to generate the Subject Numbers and then

causing and/or authorising the Subject Calls to be made to the Subject Numbers, the
Individual failed to stay within the “clear guardrails” of the PDPA to safeguard
consumer interests.

To make matters worse, numerous calls were made to the SCDF emergency

line. The importance of keeping the SCDF emergency line open and unobstructed for
genuine emergencies cannot be over-emphasised. That said, the fact that automated
marketing calls were made to the SCDF is not itself relevant to the Individual’s breach
of the Section 48B Prohibition. The issue is with the method used to generate the
Subject Numbers, and the Individual’s role in authorising the Subject Calls.

The Commission recognises that:

(a)

the Individual was cooperative with the Commission’s investigations;

(b)

the Individual has not previously contravened the PDPA;

(c)

the Individual had made efforts to ensure that he complied with his obligations
under Part 9 of the PDPA relating to the DNCR when making the Subject Calls;
and

(d)

the Individual voluntarily took action to cease the Subject Calls upon discovery
that the SCDF had been called.

Having considered all the relevant factors in this case, the Commission hereby

administers a warning to the Individual in respect of his breach of the Section 48B
Prohibition. No other directions are necessary in view of the remedial actions already
taken by the Individual.

LEE TI-TING
ASSISTANT COMMISSIONER
FOR PERSONAL DATA PROTECTION

",Warning,065914363a4287df302d4869dbb9b671721521e1
11,11,1,952,Sembcorp Marine was found not in breach of the PDPA in relation to an incident whereby threat actor(s) exfiltrated personal data by exploiting a zero-day vulnerability present in an application.,"[""Protection"", ""Not in Breach"", ""Others"", ""Ransomware"", ""No breach""]",2023-03-10,https://www.pdpc.gov.sg/-/media/Files/PDPC/PDF-Files/Commissions-Decisions/GD_Sembcorp-Marine-Ltd_070223.pdf,Protection,No breach of the PDPA by Sembcorp Marine,https://www.pdpc.gov.sg/all-commissions-decisions/2023/03/no-breach-of-the-pdpa-by-sembcorp-marine,2023-03-10,"PERSONAL DATA PROTECTION COMMISSION

[2023] SGPDPCS 2
Case No. DP-2206-B9934

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

And

Sembcorp Marine Ltd

SUMMARY OF THE DECISION

1. On 25 July 2022, Sembcorp Marine Ltd (the “Organisation”) notified the
Personal Data Protection Commission (the “Commission”) of a personal data
breach that had occurred through the exploitation of the Log4J zero-day
vulnerability (the “Incident”).

2. As a result of the Incident, the personal data of 25,925 individuals was
exfiltrated. The personal data affected included their name, address, email
address, NRIC number, telephone number, passport number, photograph, date
of birth, bank account details, salary, and medical screening results.

3. The Organisation engaged an external cybersecurity company, Sygnia, to
investigate the Incident. Its investigations found that the threat actor had
exploited three Log4J vulnerabilities present in an application (the
“Application”) to gain unauthorised access to a server as early as on 4 January
2022. The threat actor also deployed the “Cobalt Strike” beacon, conducted
reconnaissance, and made lateral movements across several machines, before
exfiltrating data between 10 and 23 June 2022, and deploying a ransomware
on 28 June 2022.

4. Threat intelligence research revealed that the ransomware campaign which
affected the Organisation began targeting users of the Application in January
2022. Given that reports of the Log4J vulnerability were first made in December
2021, it would have been difficult for the Organisation to detect and prevent the
infiltration when it was one of the early targets, having been infiltrated as early
as 4 January 2022.

5. After finding out about the Log4J vulnerability, the Organisation took prompt
actions to identify instances of Log4J vulnerabilities across all the software
application it was using. The Organisation started identifying instances of Log4J
vulnerabilities across its systems on 14 December 2021. It applied the security
patches immediately when they were made available by the respective software
vendors. The Organisation also implemented workarounds recommended by
the vendors, for systems which patches were not available or had not been
released. Additional measures such as blocking incoming and outgoing Log4J
traffic were also taken.
2

6. We are satisfied that the Organisation had made reasonable security
arrangements to protect personal data in its possession and/or control in
relation to the Incident. The Organisation had in fact adopted good practices in
relation to its Information and Communications Technology (ICT) systems. This
included a cybersecurity testing programme, regular vulnerability assessment
and penetration testing, and cyber security monitoring.

7. In view of the above, the Deputy Commissioner for Personal Data Protection is
satisfied that the Organisation had met its Protection Obligation under section
24 of the PDPA. No enforcement action therefore needs to be taken in relation
to the Incident.

The following provision(s) of the Personal Data Protection Act 2012 had been cited in
the above summary:
Protection of personal data
24. An organisation shall protect personal data in its possession or under its control
by making reasonable security arrangements to prevent –
(a) unauthorised access, collection, use, disclosure, copying, modification, disposal
or similar risks; and
(b) the loss of any storage medium or device on which personal data is stored.

",Not in Breach,fa527b079427e2423cb0a716970088f54b497254
12,12,1,952,"A financial penalty of $62,400 was imposed on Eatigo International for failing to put in place reasonable security arrangements to protect users' personal data in its possession or under its control.","[""Protection"", ""Financial Penalty"", ""Accommodation and F&B""]",2023-03-10,https://www.pdpc.gov.sg/-/media/Files/PDPC/PDF-Files/Commissions-Decisions/GD_Eatigo-International-Pte-Ltd_211222.pdf,Protection,Breach of the Protection Obligation by Eatigo International,https://www.pdpc.gov.sg/all-commissions-decisions/2023/03/breach-of-the-protection-obligation-by-eatigo-international,2023-03-10,"PERSONAL DATA PROTECTION COMMISSION

[2022] SGPDPC 9

Case No. DP-2010-B7267

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

And

Eatigo International Pte. Ltd.
… Organisation

DECISION

Page 1 of 22

Eatigo International Pte. Ltd.

Lew Chuen Hong, Commissioner — Case No. DP-2010-B7267

21 December 2022
Introduction
1.

For an organisation to effectively safeguard the personal data in its possession or

control, it must first know what its personal data assets are. The surest way to ensure such
visibility is to maintain a comprehensive personal data asset inventory. This case is, amongst
other things, a cautionary tale of the consequences of not maintaining a proper personal data
asset inventory.

On 29 October 2020, the Personal Data Protection Commission (the “Commission”)

was notified by a third party about a possible data leak by Eatigo International Pte. Ltd. (the
“Organisation”). A cache of personal data that was suspected to be from the Organisation’s
database was being offered for sale on an online forum (the “Incident”).

Facts of the Case
3.

The Organisation provides an online restaurant reservation platform which offers

incentives such as discounts to its users. In its daily operations, it regularly collects and
processes the personal data of its users in order to facilitate restaurant reservations and the
provision of incentives.

After the Commission was notified of the Incident, it informed the Organisation on 30

October 2020 of an online forum purportedly selling the personal data from various ecommerce
websites, including a database containing personal data that were suspected to have been
obtained from the Organisation. Separately, the Organisation was also notified of the Incident
Page 2 of 22

on the same day by a user and a Channel News Asia journalist. The Organisation proceeded to
carry out investigations.

The Organisation’s investigations revealed that the personal data for sale on the online

forum did not match any current databases in use by the Organisation at the time of the Incident,
but matched the structure of a legacy database which contained user data as of late 2018, when
the database was last updated (the “Affected Database”). The Affected Database was hosted
on the infrastructure of a Cloud Service Provider located in Singapore, and was previously in
use by the Organisation until 2018. Thereafter, the Organisation migrated to its current online
platform, which entailed a complete redevelopment of data storage and infrastructure. Whilst
the Organisation did not intend to continue to utilise the personal data contained in the Affected
Database, it was nevertheless retained to support the migration of data to the new platform.
After the migration, the Affected Database was not included in the Organisation’s Virtual
Private Network (“VPN”) infrastructure. Unfortunately, as the Organisation transitioned to the
current engineering team, knowledge of the Affected Database was lost.

The Organisation was unable to ascertain exactly when the threat actor gained

unauthorised access to the Affected Database. However, since the Affected Database was last
updated in late 2018, the Incident was likely to have occurred some time between 2018 and
2020 (when the Affected Database was put up for sale on an online forum). Investigations
revealed the following:

(a)

At the time of the Incident, the Affected Database was accessible from the internet and
accessible by anyone who had the requisite credentials;

(b)

None of the Organisation’s employees at the material time had knowledge of the
Affected Database or possessed the credentials to access the Affected Database;

Page 3 of 22

(c)

The databases inside the Cloud Service Provider’s Relational Database Services
(“RDS”) were intended to have randomly generated alphanumeric passwords of a
minimum 13-character length. However, there had been no such password rotation rules
implemented for the Affected Database;

(d)

There was no security review conducted on the protection provided to the personal data
contained in the Affected Database;

(e)

There was no system in place to monitor the exfiltration of large volumes of data from
the Affected Database; and

(f)

No personal data asset inventory or access logs were maintained, and the Organisation
was unable to establish how or when the threat actor gained unauthorised access to the
Affected Database.

The Affected Database held the personal data of approximately 2.76 million of the

Organisation’s users. Because the Organisation had effectively lost track of a database of that
size, network security and access control measures deployed by the Organisation were not
applied to the Affected Database.

Consequently, the Affected Database was accessed and likely exfiltrated in the Incident

and put up for sale on an online forum. A sample of 154 personal data sets were also posted on
the online forum. The types of personal data affected (the “Dataset”) were as follows:

(a)

Name;

(b)

Email;

(c)

Telephone number;

(d)

Gender;

(e)

Passwords in MD5 Hash; and

Page 4 of 22

(f)

Facebook ID number and tokens of around 10 users, which can provide access to the
Facebook accounts of users and their accounts with the Organisation’s online platform.

The personal data of a total of 154 of the Organisation’s users were displayed in the

forum post, and appeared to have been randomly selected from the Affected Database. As of
13 November 2020, the post on the online forum no longer lists the Organisation’s personal
data for sale.

10.

Upon discovery of the Incident, the Organisation implemented, or has been in the

process of implementing, the following remedial actions:

(a)

The Affected Database was securely backed-up and then deleted;

(b)

All databases were ensured to be accessible only inside VPN (i.e. no direct internet
access);

(c)

All passwords to access databases were changed as of 30 October 2020;

(d)

Affected individuals were notified;

(e)

Security Settings on Systems Infrastructure were upgraded;

(f)

Different VPN for different categories of staff were created:

(g)

Access security for data storages and cloud services was improved, including increasing
the password rotation and strengthening the password rules.

(h)

All personal data in all non-production was anonymised;

(i)

The logging and monitoring systems was reviewed to detect data access anomalies and
trace access;

(j)

Access for external services used with the Organisation’s platform was reviewed;

(k)

Penetration Testing was conducted;

(l)

All staff were updated on policies relating to network security, and subject to Data
protection and social engineering prevention training;
Page 5 of 22

(m)

All internal users in the Organisation’s cloud infrastructure and data storage were
subject to review;

(n)

Access and error logging for all databases were added;

(o)

The entire infrastructure, including which servers are currently inside vs. outside
demilitarized zone (DMZ), was subject to review; and

(p)

Accelerated implementation of recommendations of security audit completed by an
external consultant in September 2020.

Findings and Basis for Determination
The Protection Obligation under section 24 of the PDPA
11.

Based on the circumstances of the Incident as set out above, the Commission’s

investigations centred on whether the Organisation had breached its obligation under section
24 of the Personal Data Protection Act 2012 (“PDPA”) 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 (“the
Protection Obligation”).

12.

For the reasons set out below, it is determined that the Organisation failed to implement

reasonable security arrangements to protect the Affected Database from the risk of
unauthorised access. This includes a failure to ensure that the Affected Dataset was properly
accounted for in the Organisation’s personal data asset inventory, and a failure to implement
reasonable data protection processes.

13.

In determining what constitutes reasonable security steps or arrangements, an

organisation should have regard to the nature of the personal data in its possession and control,
as well as the impact that the disclosure of the data might have on the affected persons. As

Page 6 of 22

stated in the Commission’s Advisory on Key Concepts in the PDPA (the “Advisory”)1 at
[17.2]:
“There is no ‘one size fits all’ solution for organisations to comply with the Protection
Obligation. Each organisation should consider adopting security arrangements that are
reasonable and appropriate in the circumstances, for example, taking into consideration
the nature of the personal data, the form in which the personal data has been
collected (e.g. physical or electronic) and the possible impact to the individual
concerned if an unauthorised person obtained, modified or disposed of the
personal data. For example, in the employment context, it would be reasonable to
expect a greater level of security for highly confidential employee appraisals as
compared to more general information about the projects an employee has worked on.”

14.

The Affected Database contained personal data relating to approximately 2.76 million

individuals, encompassing personal data such as passwords, access IDs and Facebook tokens.
Given the high volume of personal data contained in the Affected Database, it was incumbent
on the Organisation to implement policies and practices to meet such security needs to
discharge its obligation under the Protection Obligation.

Lapses in managing of personal data asset inventory
15.

For organisations with substantial personal data assets, the maintenance of an accurate

and up-to-date personal data asset inventory is a pre-requisite for complying with the Protection
Obligation. The personal data asset inventory should catalogue all personal data assets in the
organisation’s possession or control, so as to ensure that such personal data is covered by the
organisation’s security measures. Maintaining such an inventory ensures that the organisation

Advisory Guidelines on Key Concepts in the PDPA (Rev 1 February 2021)
Page 7 of 22

retains the necessary institutional memory of the personal data assets that is or was previously
under its possession or control even if there is turnover of staff. Any significant lapse in an
organisation’s inventory management and maintenance would impair the organisation’s ability
to know whether the data protection processes it implemented are sufficient to cover all its
personal data assets.

16.

This requirement to maintain a personal data asset inventory is not novel. As stated in

Re Management Corporation Strata Title Plan No. 3400 [2020] SGPDPC 10 at [13]:
“In addition, it is important for an organisation to be aware of and track its
personal data assets. The creation and maintenance of a personal data asset
register (i.e. a record identifying all personal data in the organisation’s possession
or control) is a good practice that would assist organisations to comply with the
Protection Obligation. An up-to-date personal data asset register provides the
organisation with an accurate record of all the personal data in its possession or
control, and enables the organisation to ensure its periodic security reviews covers
the personal data assets. It also enables the organisation to more effectively review
the implementation of its data protection policies, for example, the access control
list setting out the employees who have access to the IT systems the personal data asset
is stored in, whether the internal business owner of the personal data asset has reviewed
it for data quality issues, and initiating the process for disposing personal data that have
reached the end of its life cycle within the organisation.”
(emphasis added)

17.

Similarly, it was stated in Re Civil Service Club [2020] SGPDPC 15 at [15]:

Page 8 of 22

“From the Appointed Day, the Organisation’s failure to take any reasonable steps to
ensure sufficient obligations are imposed on the Vendor (when developing and
troubleshooting the CMS, Membership Portal and Virtual Cards) to protect the
Members Data was a breach of its obligations under section 24 of the PDPA. A period
of about five years had elapsed since 2 July 2014 to 2 July 2019. The Organisation, as
owner of the CMS, should have included it as part of its personal data asset
inventory and ensured that its data protection policies covered personal data held
in the CMS. Had this been done, the Organisation would have identified these gaps
in the business requirements for the CMS, which would have set it down the path
to rectifying these gaps through one or both of the options discussed in the
preceding paragraph. The Organisation, as owner of the CMS, is responsible for
identifying the omission and articulating its business requirements relating to the
protection of personal data stored in the CMS. This would have led to action by the
Vendor in recommending technical fixes to enhance the CMS. It is the failure to identify
the omission and articulate business requirements, and for a not-trivial period of five
years, that is the gravamen of the Organisation’s breach of the PDPA.”
(emphasis added)

18.

In this connection, the Commission’s Guide to Developing a Data Management

Programme (the “Guide”) states that an organisation should establish a personal data asset
inventory as part of Data Protection Impact Assessment (“DPIA”), and sets out the information
that should be recorded by the organisation at pages 13 and 23:
“By conducting a DPIA, an organisation would be in a better position to assess if the
handling of personal data complies with the PDPA or data protection best practices,
and to implement appropriate policy, technical or process measures. For more

Page 9 of 22

information on the DPIA, please refer to the Guide to Data Protection Impact
Assessments.

As part of a DPIA, it is recommended to establish a data inventory (see Data
Inventory Maps, Data Flow Diagrams and Other Registers on page 23) and classify the
risk level of the data in the context that it is collected, used and disclosed
throughout the data life cycle, from creation, distribution, storage, to disposal.
This may be mapped onto a risk matrix for assessment and implementation of
appropriate control for the identified risk levels.

...
Data Inventory Maps, Data Flow Diagrams and Other Registers

Known risks should be managed through a good understanding of the life cycle and
flow of personal data in your organisation. This can be done through documenting the
personal data handled using diagrams and charts such as data inventory maps or data
flow diagrams, as illustrated in Annex C.

The data inventory map and data flow diagram should also include information
on the business purposes for collection, use and disclosure of personal data, the
individuals and third parties who handle personal data under the organisation’s
possession or control, as well as the classification of the data to manage user access.
They should also deal with when and how the organisation should dispose of or
anonymise the personal data for long-term archival. As good practice, it is important
that employees and third parties access personal data on a need-to-know basis. Different
sets of data may be accessed by different parties.”
(emphasis added)

Page 10 of 22

19.

In the present case, the Organisation’s oversight in failing to maintain the Affected

Database in its personal data asset inventory resulted in the omission to extend its extant
security arrangements to the Affected Database. This resulted in the following:

(a)

The Organisation did not maintain proper records of the Affected Database and was
unable to locate documentation related to user permission for the Affected Database.
There was a dearth of records of the details of the data lifecycle of the personal data in
the Affected Database from collection to disposal.

(b)

After the re-development and migration of the Organisation’s online platform, the
Organisation did not conduct a proper handover of the Affected Database despite the
turnover in staff. This led to the Organisation’s engineering team in 2020 having no
knowledge of the existence of the Affected Database or its access credentials.

(c)

Since the Organisation lacked visibility of the Affected Database, it was omitted from
the Organisation’s periodic security review. The Organisation thus did not have the
opportunity to assess whether the Affected Database needed to be retained, or whether
its security arrangements should be updated. During the Commission’s investigations,
the Organisation indicated that the Affected Database should not have been retained
following the successful migration of the Organisation’s online platform in 2018. It
stands to reason that if the Organisation had covered the Affected Database in its
periodic security reviews and assessed that it should be deleted, the Incident could have
been prevented.

(d)

Since the Affected Database was effectively forgotten about, the Organisation also did
not put in place any systems to monitor the exfiltration of data from the Affected
Database, thus impeding its ability to react swiftly to mitigate the effects of the Incident.
Page 11 of 22

20.

The Organisation’s negligence in this regard left an internet-accessible database

containing the personal data of approximately 2.76 million individuals (i.e. the Affected
Database) outside its data protection architecture, creating a clear vulnerability that was
exploited by threat actors.

21.

The Organisation’s poor knowledge management often led to it providing inconsistent,

extraneous and dilatory responses to the Commission’s notices to produce specified
information and documents (“NTPs”) relating to the Organisation’s access models, causing the
Commission to expend substantial time and resources to seek various rounds of clarifications
with the Organisation. This includes, but is not limited to, the following responses to the
Commission’s NTPs:

(a)

On 16 November 2020, the Organisation stated that the Affected Database was only
accessible through VPN via certificates. After the Commission sought further
clarifications, the Organisation stated on 14 December 2020 that it was in fact not
included in the Organisation’s VPN structure;

(b)

On 16 November 2020, the Organisation stated that only 14 users had VPN access, but
subsequently stated on 14 December 2020 that a total of 29 users with access without
VPN; and

(c)

The Organisation also gave conflicting information about its password policies
regarding the Affected Database. On 16 November 2020, it purported to have put in
place a password policy for the Affected Database prior to the Incident. However, on
10 February 2021, it indicated that no specifically predefined password rules applied to
the Affected Database. On 4 March 2021, after further clarifications were sought, the
Organisation stated that it no longer had the username and password for the Affected

Page 12 of 22

Database, and that nobody from its engineering team had any knowledge of the
username and password.
Other lapses in the Organisation’s data protection policies and processes
22.

Besides failing to adequately maintain its personal data asset inventory, investigations

also revealed other lapses and shortcomings in the Organisation’s data protection policies and
processes. As referenced in paragraph 18, the Guide states that by establishing a personal data
asset inventory as part of an organisation’s DPIA, it would be better positioned to assess if the
handling of personal data complies with the PDPA or data protection best practices, and to
implement appropriate policy, technical or process measures. In this regard, aside from its
lapses in its management of its personal data asset inventory, the Organisation also did not
implement some other basic data protection processes.

23.

First, organisations that have a high volume of personal data within their possession

and / or control should implement sufficiently robust processes to protect personal data through
reasonable security monitoring. This ensures that organisations have sufficient situational
awareness of its network security, enabling it to react timeously to data breaches. This step is
embedded into the responsibilities of a data protection officer, as stated in the Advisory at
[21.4]:
“An organisation’s DPO plays an essential role in how the organisation meets its
obligations under the PDPA. The responsibilities of the DPO often include working
with senior management and the organisation’s business units to develop and
implement appropriate data protection policies and practices for the organisation. In
addition, the DPO would undertake a wide range of activities, which may include
producing (or guiding the production of) a personal data inventory, conducting data
protection impact assessments, monitoring and reporting data protection risks,
Page 13 of 22

providing internal training on data protection compliance, engaging with stakeholders
on data protection matters and generally acting as the primary internal expert on data
protection.”
(emphasis added)

24.

Examples of such security monitoring measures are provided in the Commission’s

Guide to Securing Personal Data in Electronic Medium at [4.1(j)] and [9.1] applicable at the
material time2:
“Conduct periodic checks for personal data stored in ICT systems. For personal
data that is not required in any form anymore, securely dispose the data (refer to
section 8). If there is a need to retain the data but not in identifiable form, e.g. for
performing data analytics, consider anonymising the data.
….
Computer networks allow communication between computers and devices that are
connected to them. Internal corporate computer networks may be connected to external
networks, such as the Internet. It is important for an organisation to ensure that its
corporate computer networks are secure. Vulnerabilities in the network may allow
cyber intrusion, which may lead to theft or unauthorised use of electronic personal data.
Defences that may be used to improve the security of networks include:
•

Intrusion prevention systems (“IPS”) - a device or software application that
monitors network or system activities and prevents malicious activities or
policy violations;

The guide has been replaced by the Guide to Data Protection Practices for ICT Systems (updated 14
September 2021), which recommends similar security monitoring measures at pages 10 and 17.
Page 14 of 22

•

Intrusion detection systems (“IDS”) – a network security appliance that monitors
network and system activities for malicious activities and may raise alerts upon
detecting unusual activities;

•

Security devices that prevent the unauthorised transfer of data out from a computer
or network;

•

Firewalls; and

•

Web proxies, anti-virus and anti-spyware software.”

(emphasis added)

25.

In this case, the high volume of personal data in the Affected Database necessitated a

higher level of security awareness through robust security monitoring. However, the
Organisation’s monitoring system extended only to performance and latency monitoring. The
Organisation did not implement security monitoring for exfiltration of sizeable volumes of data
based on pre-set limits. Given the considerable volume of personal data in the Organisation’s
possession and / or control, including the personal data of the approximately 2.76 million
individuals contained in the Affected Database, this is a reasonable security arrangement that
the Organisation should have implemented.

26.

Second, given the volume of personal data under the Organisation’s possession and /

or control, the Organisation also should carry out periodic security audits which should include
a reasonable vulnerability assessment of its IT infrastructure. This would entail the discovery
and mapping of all parts of the Organisation’s network, including the Affected Database. If
this had been carried out, it might have led to the re-discovery of the Affected Database, which
would have allowed the Organisation to take the necessary steps to either improve the security
of the Affected Database or delete it entirely. However, based on the Commission’s

Page 15 of 22

investigations, the Organisation conducted no such security audits in relation to the Affected
Database.
The Commissioner’s Preliminary Decision

27.

In determining whether any directions should be imposed on the Organisation under

section 48I of the PDPA, and/or whether the Organisation should be required to pay a financial
penalty under section 48J of the PDPA, the factors listed at section 48J(6) of the PDPA were
considered, with particular emphasis on the following factors:

Mitigating Factors
(a)

The Organisation had implemented the remedial measures set out in paragraph
10 swiftly to address the Incident.

Aggravating Factors
(b)

The Organisation was grossly negligent in its failure to keep proper records or
documentation of the Affected Database and to effect a proper handover to new
employees vis-à-vis the Affected Database. Most egregiously, there was no
institutional memory amongst the Organisation’s employees of the Affected
Database by late 2020, or of the access credentials.

(c)

The Organisation had left the Affected Database exposed to a risk of
unauthorised access and exfiltration for a protracted period of time, from
October 2018 to late 2020.

(d)

As stated in paragraph [21], the Organisation’s dilatory responses to the
Commission’s NTPs resulted in delays in the investigations.

Page 16 of 22

28.

Additionally, the Organisation also impeded the Commission’s investigations by

responding in an uncooperative and evasive manner to the Commission’s NTPs:

(a)

The Organisation objected to the Commission’s request for information about the
access models implemented for current production databases, giving the excuse that it
might create “additional security risks”; and

(b)

Similarly, objecting to provide information regarding access to the Affected Database,
citing the reason that this was against their policy and might create “additional security
risks” even though the Affected Database had already been deleted on 3 November
2020.

29.

Organisations that are uncooperative and that throw up objections will only prolong

investigations. The Commission will not be deterred by such tactics. If, as is possible in this
case, the Organisation did not have the information or needed more time to recover the
information, honesty is the best policy. Hiding behind vague notions like “additional security
risks” without providing details can and will be interpreted as cavalier and obstructive, and will
be taken as an aggravating factor when the eventual outcome is determined.

30.

Based on the foregoing, the Commission made a preliminary decision to impose a

financial penalty on the Organisation for its breach of the Protection Obligation.

Representations Made by the Organisation

31.

The Organisation was notified of the preliminary decision by way of the Commission’s

letter dated 26 November 2021 and was invited to make representations. On 10 December
2021, the Organisation made the following representations to the Commission urging the
Commission to impose a warning in lieu of a financial penalty, or to reduce the financial
penalty to be imposed:
Page 17 of 22

(a)

The Organisation had not intended to frustrate the Commission’s investigation.

Instead, the Organisation’s internal investigations and responses to the Commission’s
NTPs were hampered due to diminished corporate knowledge of the Affected Database
at the material time and the impact of the COVID-19 pandemic on its management and
operations. In support, the Organisation stated that:
i. On July 2018, the Organisation’s former Chief Technology Officer (“CTO”)
resigned, with the various back-end engineers that he recruited following suit.
Consequently, the new CTO and team of back-end engineers lacked corporate
memory and had no knowledge of the Affected Database;
ii. The internal investigations on the Incident were hampered by turbulence in the
Company's organisation during the Covid-19 pandemic, and despite the steps
taken to maintain system documentation, the Affected Database was not
uncovered; and
iii. The conduct cited in [21] and [28] above stemmed from a misunderstanding of
the Commission’s queries and the new CTO, being from a different cultural
background, being reluctant to provide sensitive data to the Commission;
(b)

The contemplated financial penalty in the preliminary decision would be

crushing on the Organisation and would likely lead to financial distress and the closure
of its business. As the Organisation operates in the food and beverages industry, its
business suffered during the COVID-19 pandemic and left it in a risky financial position
from which is it has yet to recover from. Any financial penalty imposed would
adversely affect the Organisation’s business, and deter any further investors or lenders
from providing any further loans or investments to the Organisation; and

Page 18 of 22

(c)

The impact of the Incident was limited. The Organisation raised the following

points in support:
i. The Organisation did not collect NRIC numbers, birth dates and sensitive
financial data such as credit card information. The login passwords that were
collected were encrypted using MD5 Hash ;
ii. As of 10 December 2021, the Company received less than 100 requests from
users to delete their accounts following the Incident; and
iii. The online forum post initially offering personal data from the Affected
Database for sale appears to have been taken down as of 13 November 2020.
Diminished corporate knowledge and conduct during the Commission’s investigations

32.

The Organisation’s representations in [31(a)] do not merit a waiver or reduction in the

financial penalty imposed. Staff turnover is no excuse for a lack of corporate knowledge, and
it is incumbent on organisations to take reasonable steps to bolster institutional memory to
manage any security risks arising thereof. This includes the implementation of practices such
as the maintenance of a personal data asset inventory as detailed in [16] to [18], which would
have enabled it to conduct proper handovers to new staff.

33.

As for the difficulties experienced by the Organisation during its own internal

investigations and any misunderstandings it may have had in relation to the Commission’s
NTPs, it should have been candid with the Commission about its difficulties and sought
clarifications and extensions of time to respond to the NTPs. Instead, its lack of transparency
during the investigation stage caused the Commission to expend substantial time and resources
in engaging the Organisation. In its representations, the Organisation has also admitted that it

Page 19 of 22

should have substantiated its position during the NTP stage to avoid giving the Commission
the impression that it was being uncooperative and evasive.

Likely impact of a financial penalty on the Organisation

34.

One of the considerations in the imposition of a financial penalty is the likely impact of

the imposition of such penalty on an organisation, including the ability of the organisation to
continue its usual activities: see section 48J(6)(i). When determining the appropriate financial
penalty, the Commission has consistently considered the financial circumstances of the
organisation or person involved, bearing in mind that financial penalties imposed should avoid
imposing a crushing burden or cause undue hardship on the organisation or person3.

35.

After careful consideration, the Commission accepts the Organisation’s representation

at [31(b)] that the imposition of the financial penalty proposed would likely lead to financial
distress and the closure of its business. However, a mere warning is inappropriate in view of
the egregiousness of the Organisation’s breach of the PDPA and the impact of the Incident.
Hence, the imposition of a reduced financial penalty, to be paid out in instalments, would be
more proportionate and appropriate in ensuring the Organisation’s compliance with the PDPA.

36.

In arriving at its decision, the Commission had regard for the following factors

concerning the Organisation’s financial situation, and the likely impact that the proposed
financial penalty in the preliminary decision would have on it:
(a)

In the Organisation’s audited financial statements for the financial year ending

31 December 2020, its independent auditor stated that there was significant doubt on

Re Jigyasa [2021] SGPDPCR 1; Commeasure Pte Ltd [2021] SGPDPC 11; and Neo Yong Xiang (trading as
Yoshi Mobile) [2021 SGPDPC 12
Page 20 of 22

the ability of the Organisation to continue as a going concern and to realise its assets
and discharge its liabilities in the ordinary course of business;
(b)

The Organisation’s monthly income statements from 2021 indicated that it was

incurring heavy net losses on a month-to-month basis (with the exception of one
month); and
(c)

37.

The Organisation had various substantial short-term loans due in the near future.

The above evinces a clear picture of an organisation in a parlous financial situation

caused by the COVID-19 pandemic, with various debts and liability (some incurred to keep
the business afloat) coming due in the near future. In view of this situation, the Commission
shall refrain from imposing a financial penalty that might push the Organisation’s business
even closer to the brink.

Impact of the Incident

38.

The Commission had already taken into account the impact of the Incident when

calibrating the financial penalty in the preliminary decision. At the same time, the Commission
also took into consideration the fact that the Affected Database contained the personal data of
a very high number (2.76 million) of individuals, which necessitated the implementation of
more robust security measures by the Organisation. The impact of the Incident should not be
minimised, and the financial penalty imposed should reflect this.

Acceptance of the Commission’s findings

39.

Additionally, the Commission notes that the Organisation voluntarily accepted the

Commission’s findings in the preliminary decision that it had failed to comply with the
Protection Obligation and explicitly indicated that it would not seek to challenge these findings.
Page 21 of 22

The Organisation’s voluntary acceptance of liability (even at this late stage) ought to be
reflected in the financial penalty. Had the Organisation accepted responsibility for the Incident
at an earlier stage of the investigation, it could have significantly shortened the time for
investigations and resolution of this case through the expedited breach procedure and also
benefited from greater mitigatory considerations. Nonetheless, an organisation that voluntarily
accepts responsibility for its non-compliance with the PDPA should be recognised as an
organisation that demonstrates its commitment to the Accountability Obligation and shows that
it can be responsible for the personal data in its possession or under its control4: see [46] of
Farrer Park Hospital Pte Ltd [2022] SGPDPC 6.

40.

Having considered all the relevant factors in this case including the representations

made by the Organisation, the Commission hereby requires the Organisation to pay a financial
penalty of $62,400 in 12 monthly instalments by the due dates as set out in the notice
accompanying this decision, 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.

41.

In view of the remedial actions already been taken by the Organisation, no further

directions need be issued to the Organisation

YEONG ZEE KIN
DEPUTY COMMISSIONER
FOR COMMISSIONER FOR PERSONAL DATA PROTECTION

4 Refer to section 11(2) of the PDPA.

Page 22 of 22

",Financial Penalty,d2f8ccda43f78a0b1e149fae38950a4570f436dc
13,13,1,952,Directions were issued to CPR Vision Management Pte Ltd to conduct a security audit of its technical and administrative arrangements for the protection of personal data in its possession or control and rectify any security gaps identified in the audit report. This is pursuant to a data breach incident where CPR Vision Management Pte Ltd’s server and network storage devices were subjected to a ransomware attack.,"[""Protection"", ""Directions"", ""Others"", ""Ransomware"", ""Data Intermediary"", ""Retention""]",2023-02-10,https://www.pdpc.gov.sg/-/media/Files/PDPC/PDF-Files/Commissions-Decisions/Decision---CPR-Vision-Management-Pte-Ltd---071222.pdf,Protection,Breach of the Protection Obligation by CPR Vision Management Pte Ltd,https://www.pdpc.gov.sg/all-commissions-decisions/2023/02/breach-of-the-protection-obligation-by-cpr-vision-management-pte-ltd,2023-02-10,"PERSONAL DATA PROTECTION COMMISSION
[2022] SGPDPCS 17
Case No. DP-2207-B8974

In the matter of an investigation under section 50(1) of the
Personal Data Protection Act 2012
And
CPR Vision Management Pte Ltd
L’Oreal Singapore Pte Ltd
L’Occitane Singapore

SUMMARY OF THE DECISION

1. The Personal Data Protection Commission (the “Commission”) received data
breach notification reports from (i) L’Oreal Singapore Pte Ltd (“L’Oreal”) on 29
October 2021 and (ii) L’Occitane Singapore Pte Ltd (“L’Occitane”) on 1 November
2021 respectively of a ransomware attack on their customer relationship
management (“CRM”) system vendor, CPR Vision Management Pte Ltd (the
“Organisation”). The Organisation is a data intermediary that helped to process
personal data collected by L’Oreal and L’Occitane.

2. The ransomware attack affected a server and three network attached storage
(“NAS”) devices in the Organisation’s office (“office network”), and led to the
Page 1 of 6

encryption of the personal data belonging to 83,640 L’Occitane’s customers and
35,079 L’Oreal’s customers, which included their name, address, email address,
mobile number, NRIC number, date of birth, age, gender, race, nationality, loyalty
points and amount spent.

3. The Organisation requested, and the Commission agreed, for this matter to
proceed under the Expedited Decision Breach Procedure. To this end, the
Organisation voluntarily and unequivocally admitted to the facts set out in this
decision. It also admitted to a breach of the Protection Obligation under Section 24
and the Retention Limitation Obligation under Section 25 of the Personal Data
Protection Act (the “PDPA”).

4. The Organisation’s internal investigations found the threat actor had first gained
access to the office network via a compromised user account VPN connection on
13 October 2021 before executing the ransomware attack on or about 15 October
2021. However, due to the limited data logs available on the Organisation’s
FortiGate firewall and VPN appliance, the Organisation was not able to determine
how the threat actor gained access to the compromised user account VPN. As part
of the immediate remediation efforts, the Organisation reset the credentials of the
compromised user account VPN and the password credentials of all VPN accounts
across the Organisation.

Page 2 of 6

5. The Organisation admitted that its endpoint security solution would have been able
to detect and block the unauthorised entry attempts to the office network affected
in the Incident. However, the Organisation failed to extend the deployment of this
protection solution to the affected office network. This could have been because
the domain controller server within the affected office network had been earmarked
to be decommissioned after the data was copied to MS365 Sharepoint. Another
reason for the omission may have been the fact that the Organisation set up the
affected office network for business continuity purposes, when it shifted to its new
premises, sometime between 6 – 9 April 2020, on the eve of the nation-wide
COVID-19 circuit breaker in Singapore.

6. The Commission finds the Organisation in breach of the Protection Obligation as it
failed to have reasonable security arrangements in place to protect the personal
data in its possession and control. As a CRM system vendor, the Organisation
processes and processed a high volume of web traffic containing personal data on
behalf of many e-commerce retailers, including L’Oreal and L’Occitane, and would
ordinarily be held to a higher standard. The Organisation’s omission to deploy its
endpoint security solution to the affected office network suggests that the
Organisation failed to maintain an inventory of its data assets.

7. Even if there were extenuating circumstances in April 2020 which could have partly
excused the Organisation’s omission to include the affected office network in its
data inventory, it was inexcusable for the Organisation to let this state of affairs
Page 3 of 6

persist for more than one and-a-half years, from April 2020 until October 2021. We
should add however, that as part of its remediation efforts, the Organisation has
since ensured that its endpoint security solution was deployed to all office and enduser devices.

8. The Organisation also admitted to being in breach of the Retention Limitation
Obligation. The Organisation admitted that the affected personal data in the
Incident had been legacy content, which should have been deleted together with
the domain controller server earmarked for decommissioning, and for which no
business or legal purpose existed for retention. The Organisation highlighted
however, that this lapse was not in accordance with its own data retention policy.
Had the Organisation complied with the Retention Limitation Obligation and
deleted the personal data in question, the Incident would not have amounted to a
breach of the Retention Limitation Obligation under the PDPA.
9. In the course of our investigations, L’Oreal furnished documentary evidence which
showed that L’Oreal had specifically instructed the Organisation, pursuant to its
data retention policies, to delete the affected personal data on 26 March 2021. This
was duly acknowledged by the Organisation, and the Organisation furnished a
purported Certificate of Destruction dated 17 May 2021 stating that the personal
data had been deleted on 6 May 2021.

Page 4 of 6

10. Similarly, L’Occitane also raised its concerns that the Organisation failed to seek
its prior written consent before duplicating the personal data to other nonproduction environments.
11. The Commission is satisfied that neither L’Oreal nor L’Occitane had any knowledge
of the retention and storage of the legacy personal data by the Organisation on the
affected NAS device; and neither had any control over the NAS device used by the
Organisation to store the personal data affected by the ransomware attack. Both
L’Oreal and L’Occitane had also adequately provided in their contracts with the
Organisation to ensure compliance with the Protection and Retention Limitation
Obligations under the PDPA. The Commission is therefore of the view that despite
the personal data breach incident, L’Oreal and L’Occitane had acted consistently
with and complied with the relevant obligations under the PDPA.
12. Having considered the circumstances set out above, including the Organisation’s
upfront admission of liability, and the fact that data analysis conducted by the data
security team of the Organisation’s parent company did not uncover any evidence
to suggest that data exfiltration or modification had occurred, the Commission
considered that it would be most appropriate in lieu of imposing a financial penalty,
to direct the Organisation to comply with the following action:
a. Conduct a thorough security audit (with report) of its technical and
administrative arrangements for the protection of personal data in its possession
or control;
b. Rectify any security gaps identified in the security audit report;
Page 5 of 6

c. Conduct a comprehensive review of all of the Organisation’s databases
containing personal data to ensure full compliance with the Retention Limitation
Obligation under Section 25 PDPA;
d. Review and update the personal data policies of the Organisation as applicable,
including clarification of the roles of data intermediaries and vendors in complying
with the Retention Limitation Obligation under section 25 of the PDPA, within 60
days from the date the security audit report is delivered to the Organisation; and
e. Inform the Commission within 1 week of the completion of the steps directed
above.

The following are the provision of the Personal Data Protection Act 2012 cited in the above summary:
Protection of personal data
24. An organisation must protect personal data in its possession or under its control by making
reasonable security arrangements to prevent –
(a) unauthorised access, collection, use, disclosure, copying, modification or disposal or similar risks
and;
(b) the loss of any storage medium or device on which personal data is stored.
Retention of personal data
25. An organisation must cease to retain its documents containing persona data, or remove the means
by which the personal data can be associated with particular individuals, as soon as it is reasonable to
assume that –
(a) the purpose for which the personal data was collected is no longer being served by retention of the
personal data; and
(b) retention is no longer necessary for legal or business purposes.
Page 6 of 6

",Directions,7e9168136ea5e122bc3f4577c70535e0fc6c7689
14,14,1,952,"RedMart had failed to obtain consent and inform its suppliers of the purpose for collecting images of the physical NRICs and other identification documents. However, the Commission had subsequently assessed that RedMart had met the requirements for reliance on the Legitimate Interests Exception and complied with the proposed direction. As such, no direction was issued to RedMart.","[""Consent"", ""Notification"", ""Purpose Limitation"", ""No Further Action"", ""Wholesale and Retail Trade""]",2023-02-10,https://www.pdpc.gov.sg/-/media/Files/PDPC/PDF-Files/Commissions-Decisions/Decision---RedMart-Limited---18012023.pdf,"Consent, Notification, Purpose Limitation","Breach of the Consent, Notification and Purpose Limitation Obligations by RedMart","https://www.pdpc.gov.sg/all-commissions-decisions/2023/02/breach-of-the-consent,-notification-and-purpose-limitation-obligations-by-redmart",2023-02-10,"PERSONAL DATA PROTECTION COMMISSION

Case No. DP-2105-B8405

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

And

RedMart Limited
… Organisation

DECISION

Page 1 of 11

RedMart Limited

[2023] SGPDPC 1

Yeong Zee Kin, Deputy Commissioner — Case No. DP-2105-B8405
18 January 2023

Introduction

On 31 May 2021, the Personal Data Protection Commission (the “Commission”)

received a complaint that RedMart Limited (the “Organisation”) was collecting images
of the physical NRICs and other identification documents of suppliers making
deliveries to its warehouses (the “Incident”), and that this practice did not appear to
be in compliance with the Personal Data Protection Act 2012 (“PDPA”).

Facts of the Case

Investigations revealed that the Organisation operated two warehouses at 47

Jalan Buroh, CWT Distripark, Singapore 619491 (“Warehouses”) which were used to
store goods and produce sold by the Organisation. The Warehouses were regularly
visited by suppliers delivering goods and produce (“Visitors”), and the Organisation
implemented measures to regulate such Visitors’ access to the Warehouses. Security
checkpoints at the Warehouses used an Organisation-issued tablet computer

Page 2 of 11

(“Tablet”) to take photographs of Visitors’ NRIC or other identification documents (“ID
Photographs”). The Organisation said it collected ID Photographs to Visitors seeking
access to areas where food safety risks had to be managed. The Organisation
explained that these measures are intended to deter acts that could compromise food
safety and facilitate investigations of food safety incidents.

Prior to the Incident, there were no notices at the Warehouses’ security

checkpoints informing Visitors of the purpose for collection of ID Photographs. After
being notified by the Commission of the Incident, the Organisation put up notices at
the Warehouses’ security checkpoints to inform Visitors of the purpose of collection of
ID Photographs.

Findings and Basis for Determination

Considering that the Tablets remained in the possession of the Organisation’s

security team at all times, and that there was no evidence of misuse of the ID
Photographs collected, the impact of the Incident was limited. Having collected the ID
Photographs, the Organisation is obliged to protect these and associated personal
data to a standard commensurate to the risks that unauthorised access, use or
disclosure might pose to respective individuals. The nub of the issue in this case is the
legal basis upon which these ID Photographs were collected. The Organisation could
have relied on two possible grounds.

Page 3 of 11

First, Visitors may have volunteered their IDs to be photographed on request.

However, the Organisation’s failure to inform Visitors of the purpose for collecting the
ID Photographs was contrary to sections 14(1)(a) and 18(b) of the PDPA read with
section 20. Further, the collection of a photographic image of their IDs was a condition
for entry. Visitors enter the Warehouses to make deliveries as part of their employment
or business. It is not a product or service that they chose to access, as contemplated
by section 14(2)(a) of the PDPA. Hence, even if the requirement of notification of
purpose had been met, this is not a situation where persons making deliveries as part
of their employment or business could be said to have consented to allowing a
photographic image of the IDs to be taken as a condition for a product or service
provided by the Organisation which such persons wanted access to. Consent is not
the most appropriate basis for collection and use of the ID Photographs. Accordingly,
the Organisation did not obtain valid consent from the Visitors for collecting the ID
Photographs, and would have breached section 13 of the PDPA if this ground was
relied on.

There was an alternate ground available to the Organisation. The purpose of

public food hygiene and safety, cited by the Organisation in the present case, is a
legitimate interest of the Organisation, and also of its business partners and ultimately,
consumers. Ensuring good public hygiene and safety benefits all downstream food
and beverage businesses, supermarkets and diners who eventually consume food
that was stored in the Warehouses. The Organisation may therefore rely on the
exception at Paragraph 1, Part 3 of the First Schedule of the PDPA (“Legitimate

Page 4 of 11

Interests Exception”) to collect the ID Photographs without Visitors’ consent. The
Legitimate Interests Exception was introduced in the PDPA effective 1 February 2021,
and could have been invoked by the Organisation any time after this date.

To rely on the Legitimate Interests Exception, prior to collecting the ID

Photographs, the Organisation would have had to conduct and document an
assessment determining whether the Organisation’s interests in collecting the ID
Photographs outweighed the adverse effect to Visitors. For any adverse effects
identified, the Organisation would have had to implement reasonable measures to
eliminate, mitigate or reduce the likelihood of occurrence. The Organisation would also
have had to provide Visitors with reasonable access to information about the
Organisation’s collection of the ID Photographs, which could have been done by way
of disclosure in the Organisation’s public data protection policy.

The Commission accepts that the Organisation implemented access controls to

regulate how the ID Photographs were collected and stored, which in turn reduced the
risk of misuse of the ID Photographs. Notwithstanding, based on the reasons provided
by the Organisation, the collection had been solely or primarily to deter acts that could
compromise food safety and facilitate investigations into food safety incidents. The
collected ID Photographs contained full NRIC / ID numbers together with other
personal information that, in combination, had identified Visitors to a high degree of
fidelity. The Commission noted that the collection of ID Photographs or full NRIC
numbers had not been required by law in this case, and it is incumbent on the

Page 5 of 11

Organisation to justify why the collection of ID Photographs had been a reasonable
practice in these circumstances.

The Commission’s Preliminary Decision

In view of the above, bearing in mind that the Organisation had taken some steps

to remediate the Incident, the Commission’s preliminary decision was to give the
following directions to the Organisation:

(a)

To within 60 days of this decision, conduct and document an assessment to:

(i)

evaluate whether the collection of ID Photographs from Visitors is
reasonably necessary for the Organisation’s interests in deterring and
investigating security incidents at the Warehouses.

(ii)

If the Organisation intends to rely on the Legitimate Interests Exception for
such collection, to:

(A)

identify whether the Organisation’s collection of ID Photographs (or
other personal data) from Visitors is likely to have an adverse effect
on Visitors;

(B)

identify reasonable measures that could be implemented to eliminate,
mitigate, or reduce the likelihood of such adverse effects occurring;
and

Page 6 of 11

(C) determine whether the Organisation’s interest in collecting the ID
Photographs (or other personal data) outweighs the adverse effect to
Visitors (if any) after the above measures are implemented.

(iii)

If the Organisation does not intend to rely on the Legitimate Interests
Exception, to identify the basis under which the Organisation intends to
collect the ID Photos (or other personal data) from Visitors, and to
implement the necessary policies and processes for such collection to be
in compliance with the PDPA.

(b)

To provide the Commission with a copy of the Organisation’s above assessment
within 14 days of its completion.

The Organisation’s Representations

The Commission’s preliminary decision was communicated to the Organisation

on 8 July 2022. On 22 July 2022, the Commission received representations from the
Organisation in respect of the preliminary decision. The Organisation claimed that it
had complied with the PDPA when collecting ID Photographs from Visitors, on the
following bases:

(a)

It was in the national interest to collect ID Photographs in order to establish the
identities of Visitors to a high fidelity and deter potential food security incidents

Page 7 of 11

at the Warehouses, an exception to the obligation to obtain consent pursuant to
Paragraph 2, Part 2 of First Schedule to the PDPA (“National Interest
Exception”);
(b)

The collection of ID Photographs was necessary to facilitate investigations into
food security incidents at the Warehouses, an exception to the obligation to
obtain consent pursuant to Paragraph 3, Part 3 of First Schedule to the PDPA
(“Investigations Exception”); and/or

(c)

There was deemed consent from Visitors for collection of the ID Photographs, as
these were volunteered, and collected for the reasonable purposes as part of
efforts to ensure food security (pursuant to section 15 of the PDPA).

The Organisation’s representations are not accepted:

(a)

The National Interest Exception does not apply. The Organisation’s food security
concerns, while valid, are limited to its own Warehouses and are not at the level
of the “national defence or “national security” concerns contemplated by the
definition of “national interest” at section 2 of the PDPA.

(b)

The Investigations Exception does not apply. In order to rely on the Investigations
Exception, the collection of personal data must be for the purpose of an ongoing
investigation and cannot be for a hypothetical future investigation.

(c)

There was no deemed consent from Visitors for the Organisation’s collection of
the ID Photographs. Visitors were not given a choice in the matter and cannot be
said to have voluntarily provided their IDs as contemplated under section 15(1)

Page 8 of 11

of the PDPA. Further, it would not have been obvious to Visitors that fact that
photographic images of IDs would be taken and then stored.

Insofar as collection and use of ID Photographs from Visitors prior to 8 July 2022

had been on the bases cited by the Organisation above, the Commission finds that
the Organisation had not been in compliance with the PDPA.

Reliance on Legitimate Interests Exception

However, the Organisation also informed the Commission of its intention to rely

on the Legitimate Interests Exception as the basis for such collection going forward.
Together with its representations, the Organisation provided the Commission with a
copy of an internal assessment it had carried out on 22 July 2022 for its reliance on
the Legitimate Interests Exception going forward (“LIE Assessment”).

In the LIE Assessment, the Organisation identified that there was a need to

establish and/or verify the identities of Visitors to the Warehouses to a high degree of
fidelity, when they were entering areas of the Warehouses containing dry food and
fresh produce that were susceptible to contamination and tampering. Collection of ID
Photographs served the legitimate interests of deterring and investigating potential
food security incidents, which could cause harm to the public and damage to the
Organisation’s reputation.

Page 9 of 11

The Organisation identified that its collection of the ID Photographs exposed

Visitors to the risks of unauthorised use and disclosure of their personal data, and
detailed the measures it had implemented to eliminate or mitigate these adverse
effects. These included:

(a)

limiting collection of ID Photographs to only Visitors accessing areas of the
Warehouses with higher risk of food security incidents;

(b)

restricting access to the Tablets;

(c)

restricting the application used to collect ID Photographs on the Tablets to only
work when connected to a dedicated Wi-Fi network at the Warehouses;

(d)

immediately uploading the collected ID Photographs to the Organisation’s
backend server (and not storing them locally on the Tablets);

(e)

limiting access to the ID Photographs (on the backend server) to the
Organisation’s DevOps team, and only when such access was on-site at the
Organisation’s offices and connected to its internal network; and

(f)

retaining the ID Photographs for a maximum of one year.

The Organisation assessed the benefit in collecting the ID Photographs to be

“significant” considering the potential harm that could be caused to the public by a food
contamination incident. The Organisation also assessed that its implementation of the
above measures rendered the “adverse impact from users” to be “low”. The
Organisation confirmed that it would notify Visitors of its reliance on the Legitimate
Interests Exception by way of notices posted at the relevant security posts.

Page 10 of 11

The Commission accepts that the Organisation’s interest in deterring food

security incidents at the Warehouses is legitimate. The Commission also accepts that
there may be a legitimate interest served in implementing enhanced identification
requirements to regulate access to high risk areas, and that the collection of ID
Photographs promote this interest. Most importantly, the Commission recognises that
the risks of unauthorised access, use and/or disclosure of the ID Photographs have
been significantly lowered on account of the enhanced access controls implemented
by the Organisation to protect the ID Photographs.

The Commission’s Decision

For the above reasons, the Commission is satisfied that the Organisation has

met the requirements for reliance on the Legitimate Interests Exception in this case.
As the Organisation has already complied with the proposed direction (contemplated
at [9] above) by carrying out the LIE Assessment to the Commission’s satisfaction, it
is no longer necessary for the direction to be issued.

YEONG ZEE KIN
DEPUTY COMMISSIONER
FOR PERSONAL DATA PROTECTION

Page 11 of 11

",No further action,4eaff99c5b7557a88a0ca128e03e4b18ea52c953
15,15,1,952,"Directions were issued to Thomson Medical to conduct scan of the web to ensure no publication of affected personal data online and to include in the review of its application deployment process, measures such as the arrangements for security testing and the implementation of data retention policy. This is pursuant to a data breach incident from an unsecured Health Declaration Portal which enabled public access to visitors' personal data.","[""Protection"", ""Directions"", ""Healthcare""]",2022-12-19,https://www.pdpc.gov.sg/-/media/Files/PDPC/PDF-Files/Commissions-Decisions/Decision---Thomson-Medical-Pte-Ltd---140922.pdf,Protection,Breach of the Protection Obligation by Thomson Medical,https://www.pdpc.gov.sg/all-commissions-decisions/2022/11/breach-of-the-protection-obligation-by-thomson-medical,2022-12-19,"PERSONAL DATA PROTECTION COMMISSION

[2022] SGPDPCS 15

Case No. DP-2010-B7246

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

And

Thomson Medical Pte. Ltd.

SUMMARY OF THE DECISION

1. On 26 October 2020, the Personal Data Protection Commission (the
“Commission”) was notified that the Thomson Medical Pte. Ltd. (the
“Organisation”) Health Declaration Portal was not secure, enabling public
access to the personal data of visitors (the “Incident”) stored in a CSV (comma
separated values) file.

2. Visitor data collected on the Organisation’s Health Declaration Portal had been
stored concurrently in a publicly-accessible CSV file as well as a secured
1

database from 16 April 2020, when the health declaration portal was first used
by the Organisation to 8 September 2020, when the storage of the visitor data
was changed to only the secured database instead of the CSV file. The CSV
file was hosted on the Organisation’s web server.

3. The Organisation admitted that, contrary to the instructions given to the
employee to switch the data storage from the CSV file to secured database
exclusively, and the organisation’s protocols, its in-house developer had
omitted to remove a software code, causing the visitor data to be stored in the
CSV file and the same in-house developer had omitted to change the default
web server configuration, thereby allowing public access to the hosted CSV file.
The switch to storage in a secured database would have ensured access
controls by requiring user login ID and secure password protection, as well as
encryption of data transfers using SSL certificates. The access controls would
ensure that only authorized users would be able to access the data.

4. The Commission’s investigations revealed that the affected CSV file contained
the personal data of 44,679 of the Organisation’s visitors, including the date
and time of visit, temperature, type of visitor (purpose of visit), name of visitor,
name of newborn, contact number, NRIC/FIN/passport number, doctor/clinic
name or room visiting, and answers to a health declaration questionnaire (which
included a declaration by the visitor that he/she did not have any symptoms or
recent exposure to the Covid-19 virus).
2

5. The Organisation accepted that it was in breach of the Protection Obligation
under section 24 of the Personal Data Protection Act (“PDPA”). The
Commission finds that the Organisation had breached section 24 of the PDPA
for two reasons.

6. First, even though the Organisation’s existing policies required the visitor data
collected to be stored in a secured database, the Organisation failed to ensure
that there were processes in place to ensure these policies and instructions
would be complied with. The Organisation stated that the in-house developer
had been the only staff in its IT department familiar with the programming
language used for the health declaration form. This, however, should not have
prevented the Organisation, as an example, from requiring the in-house
developer to demonstrate to another staff member, and for that staff member
to verify that the storage instructions had been complied with. As noted in Re
Aviva Ltd [2017] SPDPC 14, relying solely on individual employees to perform
their tasks diligently, with no oversight or supervision, is not a reasonable
security arrangement.

7. Second, the Organisation failed to conduct reasonable pre-launch testing
before the Health Declaration Portal went live. While acceptance testing and
some technical tests were conducted, there had been no security testing to
verify that there were access controls to the visitor data collected.
3

8. Having said that, it is a mitigating fact that the Organisation’s in-house
developer sought to comply with the Organisation’s policies and swiftly rectified
the software code on 8 September 2020, when he first discovered the coding
error whilst updating the health declaration questionnaire.

9. The forensic investigator engaged by the Organisation did not uncover any
evidence that the disclosed data had been exported and posted online,
including on the Dark Web. The Organisation’s server logs also revealed that
the CSV file was only accessed 4 times from 3 different local IP addresses.
Given the timing of the access instances, it is probable that these instances
were made by the complainant and by the Commission when investigating this
matter, which suggests that the impact of this Incident was limited.

10. The Commission noted a parallel between the facts of this case and Re Spear
Security Force Pte. Ltd. [2016] SGPDPC 12, in that both cases arose from a
single complaint about a potential breach of the PDPA, with no other evidence
suggesting that the personal data had actually been exposed to unauthorised
third parties due to the lapses by the Organisation.

11. The personal data exposed here included the clinic or room that the individual
intended to visit, and the reason for the visit. This could be to seek treatment,
accompany a patient, or a business visit made by a sales representative of a
pharmaceutical or medical device company. While the personal data exposed
4

included some health-related information, this had essentially been health
declaration information for the purpose of containment of the pandemic. The
information did not in fact reveal any potentially sensitive information such as
whether the visitor was Covid-19 positive.1

12. The personal data disclosed is also not on par with Re Singapore Health
Services Pte. Ltd.& Ors. [2019] SGPDPC 3 (“Singhealth”). In the Singhealth
case, we recognised the sensitivity involved in the exposure of the affected
individuals’ personal data in their “clinical episode information, clinical
documentation, patient diagnosis and health issues and Dispensed Medication
Records” as the information and personal data affected may allow one to
deduce the condition for which a patient had sought treatment, and may lead
to the unintended disclosure of serious or socially embarrassing illnesses.2
While there is some personal data in the present case which may reveal the
clinic which an affected individual had sought treatment, this is of a much more
limited scope as compared to the Singhealth case.

13. The Commission accepted that the Organisation took prompt remedial action
to contain the exposure. This include removing the affected CSV file and
changing all the passwords to the database, even though it was not affected by
the Incident. To prevent a recurrence of a similar incident, the Organisation also

Cf Re Terra Systems Pte Ltd [2021] SGPDPC 7.

2 See Re Singapore Health Services Pte. Ltd.& Ors. [2019] SGPDPC 3, at [139].

reviewed its application deployment process to take into consideration data
security, and rectified all potential gaps discovered during a vulnerability scan.

14. Given the lack of evidence suggesting that personal data had actually been
exposed to unauthorised third parties due to the lapses by the Organisation and
the limited impact of the Incident, the Commission considered that it would be
most appropriate in lieu of imposing a financial penalty, to impose directions.

15. Another factor which prompted the Commission to impose directions in lieu of
a financial penalty was the fact that at the material time, such health declaration
information was widely collected across the island. There was also a
corresponding acceptance and support from members of the public of the need
for the collection of such health declaration information in order for the relevant
authorities to effectively respond to and control the potential spread of COVID19.

16. Given the above, the Commission directs the Organisation to carry out the
following within 60 days:

a. In relation to the Organisation’s remedial action of reviewing its
application deployment process to take into consideration data security,
i. The Organisation shall ensure that the intended measures
include arrangements for reasonable pre-launch security testing
6

to be conducted before the launch of any new website,
application, portal or other online feature for the processing of
personal data; and
ii. The Organisation shall ensure that the intended measures
include the development and implementation of a data retention
policy to meet the Retention Limitation Obligation under section
25 of the PDPA.

b. In relation to the Organisation’s remedial action of scanning the Dark
Web for evidence of exfiltration of the personal data,
i. The Organisation shall conduct a scan of the Clear/Surface Web,
as well as a renewed scan of the Dark Web to confirm that there
is no evidence of publication of the affected personal data online.

c. By no later than 14 days after the above actions have been carried out,
the Organisation shall submit to the Commission a written update
providing details of the actions taken.

The following provision(s) of the Personal Data Protection Act 2012 had been cited in
the above summary:
Protection Obligation
24(a) Failure to protect personal data in its possession or under its control by making
reasonable security arrangements to prevent –
7

(a) unauthorised access, collection, use, disclosure, copying, modification, disposal
or similar risks

",Directions,2e2e404473e7fa064a0c51315f167b10b4810806
16,16,1,952,"A financial penalty of $72,000 was imposed on RedMart for failing to put in place reasonable security arrangements to protect the personal data in its possession or under its control.","[""Protection"", ""Financial Penalty"", ""Wholesale and Retail Trade""]",2022-12-19,https://www.pdpc.gov.sg/-/media/Files/PDPC/PDF-Files/Commissions-Decisions/Decision---RedMart-Limited---28102022.pdf,Protection,Breach of the Protection Obligation by RedMart,https://www.pdpc.gov.sg/all-commissions-decisions/2022/11/breach-of-the-protection-obligation-by-redmart,2022-12-19,"PERSONAL DATA PROTECTION COMMISSION

Case No. DP-2010-B7266

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

And

RedMart Limited
… Organisation

DECISION

RedMart Limited
[2022] SGPDPC 8

Lew Chuen Hong, Commissioner — Case No. DP-2010-B7266
28 October 2022

Introduction

Many organisations rely on web-based application programming interfaces (“API”) to

enable computers or computer programs to communicate and facilitate the sharing of data
between them. API keys are in turn used to authenticate users seeking to access APIs. If an
organisation fails to implement reasonable security measures to safeguard the security of their
API keys, this may allow threat actors unauthorised access to large troves of data stored within
multiple interconnected environments.

On 29 October 2020, the Personal Data Protection Commission (“the Commission”)

was notified that a database containing personal data of the customers of RedMart Limited (the
“Organisation”) was being offered for sale on an online forum (the “Incident”). Subsequently,
the Commission commenced investigations to determine whether the circumstances relating to
the Incident disclosed any breaches by the Organisations of the Personal Data Protection Act
2012 (“PDPA”).

Facts of the Case

The Organisation operated an online platform selling groceries and fresh produce to

consumers. In 2016, the Organisation was acquired by Lazada Group (“Lazada”). Thereafter,
2

the Organisation began to integrate its platform with Lazada’s online platform. The customerfacing website and mobile application ceased operations on 15 March 2019. However, on the
back end, the migration and integration of the Organisation’s system into Lazada’s system was
not completed by that time. It is worth setting out in some detail the Organisation’s information
technology architecture to understand the backdrop against which the Incident occurred.

From March 2012 until its acquisition by Lazada, the Organisation’s business

applications (including its customer facing website, mobile application, warehouse and
delivery back-end applications) were stored in RedMart’s Amazon Web Services Virtual
Public Cloud (the “AWS Environment”). The personal data of its customers and sellers were
in turn, always stored in a MongoDB database within RedMart’s Alibaba Virtual Public Cloud.
Whilst the MongoDB database is stored within cloud infrastructure that belongs to the Alibaba
Group, the Organisation remained responsible for managing its cloud environment (hereinafter,
the “RedMart Cloud”). The Organisation did not encrypt the MongoDB database, or
implement any password authentication requirement to access the MongoDB database.

After its acquisition, the Organisation’s intention was to re-design and migrate all the

relevant databases and applications from the AWS Environment into the RedMart Cloud to
facilitate its integration with Lazada’s systems and environment by March 2021. However,
given the substantial time and resources required to complete the re-design and migration, the
Organisation opted to carry out the migration in stages. Following the acquisition and as a
matter of priority, the Organisation migrated its front end, customer-facing systems to the
RedMart Cloud to enable a seamless integration into Lazada’s environment and platform for
its customers. This was completed on 15 March 2019, after which the Organisation shut down
its public-facing consumer application and website. Additionally, the MongoDB database
residing in the RedMart Cloud containing the affected customer and seller data was
3

disconnected from the application and website (the “Affected Database”), and thereafter
access by the Organisation’s customers was disabled.

In contrast, the Organisation’s back-end business applications and systems (such as

order fulfilment, inventory, transport and warehousing) and its seller portal continued to be
hosted on the AWS Environment and linked to the Affected Database contained in the RedMart
Cloud.

Concomitantly, the Organisation’s back-end systems and IT infrastructure during the

interim period was structured in the following manner:
(a)

The Organisation’s GitHub Enterprise repositories (the “GitHub Repositories”), were
accessible by the Organisation’s employees possessing GitHub user and administrative
accounts. The Organisation used the GitHub Repositories to store, amongst other
things, sensitive source codes including a Chef1 key that functioned as a high privilege
access key to the AWS Environment. The Organisation implemented the following
access control measures vis-à-vis the GitHub Repositories:
i.

For GitHub user accounts, the Organisation followed GitHub’s password policy,
which required the use of passwords which were either eight characters long if it
included a number and a lowercase letter, or 16 characters long with any
combination of characters; and

ii.

For GitHub administrator accounts, two-factor authentication (“2FA”) was
required on top of the password requirements above.

“Chef” is an orchestration tool used for automated provisioning and management purposes within an AWS
environment.
1

(b)

The AWS Environment was accessible through the Chef key, and contained various
private Simple Storage Service (“S3”) buckets 2 , one of which contained another
sensitive API key – the Hubot3 key.

(c)

Lastly, the AWS Environment was connected to the RedMart Cloud through an
OpenVPN4 connection. The Affected Database was stored within the RedMart Cloud.

The Incident

Sometime in September 2020, an unidentified threat actor (“TA”) gained unauthorised

access to the GitHub user account of a member of the Organisation’s DevOps (i.e. software
development and IT operations) team. The TA utilised the compromised GitHub user account
to search through the GitHub Repositories and found the Chef key. Thereafter the TA used the
Chef key to access the AWS Environment, whereupon he scanned through the Organisation’s
private S3 buckets and located the Hubot key.

Using the Hubot key, the TA created a rogue Amazon Elastic Compute Cloud (“EC2”)

instance in the AWS Environment. The TA also created a new firewall rule to enable a
connection between the rogue EC2 instance and another part of the Organisation’s network
hosted by the RedMart Cloud. The TA then traversed the OpenVPN connection (that linked
the AWS Environment to the RedMart Cloud) to access the RedMart Cloud.

Once the TA had gained access to the RedMart Cloud, he proceeded to exfiltrate the

Affected Database on 6 September 2020. Subsequently, the Affected Database was found on
an online forum being offered for sale.

S3 buckets are public cloud storage resources in AWS which are similar to file folders.
Hubot is a chat software that can be scripted to interact with an IT environment.
4
OpenVPN is a virtual private network system that implements techniques to create secure point-to-point or
site-to-site connections in routed or bridged configurations and remote access facilities.
3

The Affected Database contained the following personal data:

Customer accounts

Seller business accounts

Number of affected
898,791
individuals
Types of personal a. Name
a. Partial credit card number
data
b. Email address
comprising first 6 and last
c. Contact number
4 digits
d. Residential address
e. Partial credit card details b. Hashed account password
comprising:
• First 6 and last 4 digits
of card number
• Card owner’s name
• Expiry date
• Credit card billing
phone number and
billing address
• Hashed
account
password
• URL links of call
recordings between
customer
service
agents
and
the
Organisation’s
customers

Remedial actions

Following the Incident, the Organisation and Lazada implemented the following

remedial measures:
Actions to mitigate the effects of the Incident
(a)

Disabled and reset the affected Chef and Hubot keys.

(b)

Disabled the compromised GitHub user account.

(c)

Reset all other existing AWS API keys, GitHub user credentials and tokens

(d)

Deleted the EC2 instance created by the TA.

(e)

Logged out and reset of all affected customer and seller accounts on 30 October
2020.

(f)

Reviewed all of the Organisation’s servers with services connected to Internet.
All sensitive services were filtered by a firewall.

(g)

Conducted vulnerability scanning of 31 Internet facing IP addresses.

(h)

Investigated all other existing MongoDB databases to search for traces of the
TA.

(i)

Monitored the Lazada login page for brute force attacks.

(j)

Informed all affected individuals of the Incident via emails and broadcast on the
Lazada online and application platforms on 30 October 2020. A media
statement was also issued at the same time.

Actions to prevent recurrence of the Incident or similar incidents
(k)

Implemented database authentication for all databases containing personal data.
Restricted access to sensitive database from only authorised source IP addresses
instead of network ranges.

(l)

Implemented 2FA for all GitHub accounts and removed unnecessary GitHub
accounts and developer access keys.

(m)

Scanned for vulnerabilities in AWS critical Virtual Private Cloud instances.

(n)

Performed a security architecture review of the Organisation’s multiple cloud
network and intra-cloud micro-segmentation.

(o)

Reviewed all AWS Identity and Access Management user permissions to ensure
no “create instance” permission.

(p)

Set up identity access management rules to restrict geographical locations from
which API keys could be used to access the Organisation/Lazada cloud
environments.

(q)

Reviewed all user identities and access privileges for all systems and
applications used. Removed access privileges of all inactive accounts.

(r)

Implemented network traffic logging between the AWS Environment and
RedMart Cloud.

(s)

Implemented network Access Control list and endpoint detection and response
for windows instances for RedMart Cloud.

(t)

Implemented security monitoring to detect creation of any new cloud instance

(u)

Enabled Virtual Private Cloud (VPC) logs for security monitoring.

(v)

Required all of the Organisation’s employees to complete an online training
course on privacy management and responsibilities in handling personal data.

Findings and Basis for Determination
The Protection Obligation under section 24 of the PDPA

Based on the circumstances of the Incident as set out above, the Commission’s

investigation focused on whether the Organisation had breached its obligation under section 24
of the PDPA to protect personal data in its possession or under its control by taking reasonable
security steps or arrangements to prevent unauthorised access and disclosure (“the Protection
Obligation”).

In determining what constitutes reasonable security steps or arrangements, an

organisation should have regard to the nature of the personal data in its possession and control,
as well as the impact that the disclosure of the data might have on the affected persons. As
stated in the Commission’s Advisory Guidelines on Key Concepts in the PDPA (the “Advisory
Guidelines”)5 at [17.2]:
“There is no ‘one size fits all’ solution for organisations to comply with the Protection
Obligation. Each organisation should consider adopting security arrangements that are
reasonable and appropriate in the circumstances, for example, taking into consideration
the nature of the personal data, the form in which the personal data has been
collected (e.g. physical or electronic) and the possible impact to the individual
concerned if an unauthorised person obtained, modified or disposed of the
personal data. For example, in the employment context, it would be reasonable to
expect a greater level of security for highly confidential employee appraisals as
compared to more general information about the projects an employee has worked on.”
(emphasis added)

Given the high volume of personal data contained in the Affected Database

(approximately 898,791 individuals, encompassing personal data such as names, email

https://www.pdpc.gov.sg/guidelines-and-consultation/2020/03/advisory-guidelines-on-key-concepts-in-thepersonal-data-protection-act

addresses, residential addresses, contact numbers and partial credit card details), it was
incumbent on the Organisation to implement policies and practices that were commensurate
with the Organisation’s higher-level security needs to discharge its obligation under the
Protection Obligation.

For the reasons set out below, it is determined that the Organisation failed to implement

reasonable security arrangements to protect the Affected Database from the risk of
unauthorised access.

Whether the Organisations had contravened the Protection Obligation

Based on the Organisation’s IT architecture as detailed above, the Affected Database

was placed behind various levels of security controls within RedMart Cloud. This meant that
a threat actor had to get through various access points to access the Affected Database. The
implementation of network segmentation as part of layered defence is a reasonable strategy for
defence-in-depth. However, a complex IT architecture can be defeated by simple errors,
especially when the high-value data embedded within such complex systems are so often the
target of sophisticated threat actors. The complexity of the Organisation’s network architecture
does not paper over the cracks in its security arrangements – at every level of defence, the
Organisation’s systems presented clear vulnerabilities that should have been addressed.

First, the Organisation failed to implement reasonable access control on its employers’

user GitHub accounts, which allowed the TA access to the GitHub Repositories. As stated in
paragraph [7(a)], the access control measures were more stringent for GitHub administrative
accounts than for GitHub user accounts. While this adequately dealt with the differentiation of
ability to make configuration and other changes to the Organisation’s GitHub Repositories, it
did not make any distinction to the type of data stored within the repositories. This disparity in
10

access controls was not sensitive to the fact that both types of accounts had equal abilities to
access important files within the GitHub Repositories including the Chef key, which provided
access to the AWS Environment. Data with higher security implications (such as the Chef Key)
ought to be secured to a higher degree than other types of data. It is, of course, open to the
Organisation to secure all data in its GitHub Repositories at the higher level. Indeed, as stated
in paragraph 12(l), the Organisation and Lazada, as part of their remedial measures postIncident, implemented 2FA for all its GitHub accounts.

Second, the Organisation did not implement sufficient access controls to protect and

limit access to the Chef and Hubot keys, which enabled highly privileged access to various
environments within the Organisation’s systems. Not all accounts need access to the Chef and
Hubot keys; and even for accounts that had access to them, they ought to be periodically
reviewed to determine whether continued access were necessary. At an organisation-wide
level, investigations revealed that the Organisation did not conduct periodic management
reviews to ensure that the access to Chef and Hubot keys were limited to the GitHub accounts
that required such access, or to remove access from accounts that no longer needed it (including
removing unnecessary GitHub accounts altogether). This is a fundamental data security
practice. As suggested in the Commission’s Guide to Data Protection by Design for ICT
Systems6:
“12. Regularly review user accounts
This ensures that all user accounts are legitimate. There should be processes to update
or remove user accounts, for instance, when a user has left the organisation. Test
accounts should also be removed after test activities have been completed.

https://www.pdpc.gov.sg/-/media/Files/PDPC/PDF-Files/Other-Guides/Guide-to-Data-Protection-by-Designfor-ICT-Systems-(310519).ashx?la=en

Separately, there should also be a process to review user accounts regularly. The review
should include ensuring all the rights assigned are indeed necessary.”
(emphasis added)

In this connection, best practice dictates that the principle of least privilege should apply

i.e. each employee be given only the minimum level of access rights or privileges necessary
for that employee to complete an assigned operation. This would limit the damage in case a
vulnerability is exploited, as in this case where the TA gained unauthorised access to a GitHub
user account. This principle was also espoused in GitHub’s own Secure Design Principles7.
The Organisation’s failure to limit access to the Chef and Hubot keys at the material time
allowed the TA to access the Chef key, and consequently the AWS Environment, through a
GitHub user account.

On a more granular level, insufficient security measures were implemented to protect

the Chef and Hubot keys, as both were stored in plain text files that were not encrypted or even
password-protected. Specifically:
(a)

The Chef key was hardcoded in source code and stored in the GitHub repositories, and
was accessible to a large group of developers from the Organisation, Lazada and
Alibaba for the purpose of knowledge sharing. By allowing so many accounts to access
the Chef key in such a manner, the risk of exposure and exploitation was heightened.

(b)

The Hubot key was stored in plain text in an AWS private S3 bucket. Therefore, any
account that accesses the AWS Environment was able to access the Hubot key as a

https://github.com/OWASP/DevGuide/blob/master/02Design/01Principles%20of%20Security%20Engineering.md

conduit from which to access the RedMart Cloud and the Affected Database stored
therein.

The manner in which the Chef and Hubot keys were stored in the GitHub Repositories

and AWS Environment were manifestly inadequate in view of the circumstances, and this
vulnerability was exploited by the TA to access the keys after he gained access to the GitHub
Repositories and AWS Environment respectively. Ideally, such keys ought to be stored in a
separate location such as Secrets Manager within the AWS Environment (i.e. a dedicated key
vault). The Organisation should not have embedded the Chef and Hubot keys directly in the
source code. This is also reflected in AWS Access Keys best practices8, which the Organisation
should have been aware of given its usage of the AWS Environment since 2012:

“Observe these precautions when using access keys:
• Don't embed access keys directly into code. The AWS SDKs and the AWS
Command Line Tools enable you to put access keys in known locations so that
you do not have to keep them in code.”
(emphasis added)

Such best practices applies to of all platforms that use APIs, and are not confined to

AWS. They are echoed in Google’s best practices for securely using API keys9, which are
meant to apply to Google Cloud but are nevertheless apposite here:

https://docs.aws.amazon.com/general/latest/gr/aws-access-keys-best-practices.html
https://support.google.com/googleapi/answer/6310037?hl=en#:~:text=Delete%20unneeded%20API%20keys%
3A%20To,use%20the%20newly%2Dgenerated%20keys
9

“Best practices for securely using API keys

When you use API keys in your Google Cloud Platform (GCP) applications, take care
to keep them secure. Publicly exposing your credentials can result in your account
being compromised, which could lead to unexpected charges on your account. To
keep your API keys secure, follow these best practices:
•

Do not embed API keys directly in code: API keys that are embedded in code
can be accidentally exposed to the public, for example, if you forget to remove
the keys from code that you share. Instead of embedding your API keys in
your applications, store them in environment variables or in files outside
of your application's source tree.

•

Do not store API keys in files inside your application's source tree: If you store
API keys in files, keep the files outside your application's source tree to help
ensure your keys do not end up in your source code control system. This is
particularly important if you use a public source code management system such
as GitHub.

•

Restrict your API keys to be used by only the IP addresses, referrer URLs, and
mobile apps that need them: By restricting the IP addresses, referrer URLs,
and mobile apps that can use each key, you can reduce the impact of a
compromised API key. You can specify the hosts and apps that can use each
key from the GCP Console Credentials page and then create a new API
key with the settings you want, or edit the settings of an existing API key.

•

Restrict your API keys to be usable only for certain APIs: If you have multiple
APIs enabled in your project and your API key should only be used with some
of them, restrict usage of that key to those APIs. You can specify the allowed

APIs for each key from the GCP Console Credentials page and then create a
new API key with the settings you want, or edit the settings of an existing API
key.
•

Delete unneeded API keys: To minimize your exposure to attack, delete any
API keys that you no longer need.

•

Regenerate your API keys periodically: You can regenerate API keys from
the GCP Console Credentials page by clicking Regenerate key for each key.
Then, update your applications to use the newly-generated keys. Your old keys
will continue to work for 24 hours after you generate replacement keys.”

(emphasis added)

The Organisation claimed that it was constrained from implementing password

protection and encryption for the Chef and Hubot keys by technical issues, and that the
implementation of password protection or encryption was not feasible or practical given the
keys’ core administrative and automating technical functions. The mere existence of technical
issues does not exculpate the Organisation, or justify the Organisation’s decision to embed the
Chef and Hubot keys into source code. Technical issues are not insurmountable, and it is open
to the Organisation to expend the necessary time, effort and resources to troubleshoot and
resolve them. However, investigations revealed that the Organisation did not make sufficient
efforts to resolve the technical issues in a timely manner, and were thus responsible for its
difficulties in implementing access controls for the Chef and Hubot keys. More broadly, even
if the Chef and Hubot keys were not compatible with password protection or encryption, there
were a variety of other methods available to safeguard the security of the keys as set out in the
best practices set out above, such as removing unnecessary GitHub accounts, restricting access
to only certain GitHub administrative accounts or storing the keys separately in a configuration

file or a key vault. Nothing prevented RedMart from adhering to such best practices, as is
evident by the fact that all these measures were implemented after the Incident occurred.

Lastly, the Organisation also did not implement separate authentication requirements,

for the Affected Database. Once the TA accessed the RedMart Cloud, this enabled the TA to
access and exfiltrate the Affected Database. Instead, the only measures implemented to
safeguard the Affected Database were the access requirements for the RedMart Cloud
environment in general, which was circumvented by the TA through his possession of the
Hubot key. This reflects a failure of the Organisation’s attempt to deploy a reasonable “defence
in depth” strategy (despite its multiple layers of access) to safeguard the security of the Affected
Database, as it should have implemented separate authentication requirements for the Affected
Database to prepare for the contingency of someone gaining unauthorised entry into the
RedMart Cloud.

At a basic level, this should have included access controls such as password protection.

Further, given the high volume of personal data contained in the Affected Database, the
Organisation should also have taken steps to implement more stringent access controls, such
as limiting access only to certain authorised network connections / interfaces. The Center for
Internet Security MongoDB 5 Benchmark10 recommends requiring authentication of, amongst
others, users and servers before allowing access to a MongoDB database on the following basis:

“2 Authentication

This section contains recommendations for requiring authentication before allowing
access to the MongoDB database.

https://cissecurity.org/benchmark/mongodb

…

Rationale:

Failure to authenticate clients, users, servers can enable unauthorized access to
the MongoDB database and can prevent tracing actions back to their sources.

It's highly recommended that password length and complexity also be in-place. When
performing the traditional user/password authentication against MongoDB there is not
in-place intrinsic password complexity check and there is no LOCKING mechanism
with multiple failure logins. So, MongoDB is prone to brute force attacks compared
to other database systems.”
(emphasis added)

The Organisation, again, cited technical difficulties for why separate authentication

requirements were not implemented for the Affected Database. Again, such technical
difficulties could have been overcome if the Organisation had expended the effort and
resources to do so.

The Commissioner’s Decision

In determining whether any directions should be imposed on the Organisation under

the Organisation was cooperative with the Commission’s investigations,

responding to the Commission’s queries in a prompt and forthcoming manner;

(b)

the Organisation had put in place some good data de-identification practices for

the credit card numbers in its possession by redacting part of the data and storing only
partial credit card details. This reduced the sensitivity and harm that might be caused
when personal data within its control are disclosed in a data breach; and
(c)

the Organisation swiftly implemented effective measures to mitigate the effects

of the incident and prevent recurrences.

The Organisation was notified of the preliminary decision by way of the Commission’s

letter dated 2 August 2022 and was invited to make representations.

Representations Made by the Organisation
30

On 23 August 2022, the Organisation made the following representations to the

Commission seeking a reduction in the financial penalty:
(a)

The Organisation had voluntarily notified the Commission and affected

individuals of the Incident even though it was not legally obliged to do so at the material
time, as the Data Breach Notification Obligation under Part 6A of the PDPA only came
into effect on 1 February 2022;
(b)

As of the date of the representations, the Organisation was not aware of any

personal data of the affected individuals being misused as a consequence of the
Incident. In support, the Organisation stated that the data in the Affected Database
relates to data used on its previous application and website which is no longer in use.
Moreover, the data was more than 18 months out of date, and was not linked to any
current Lazada databases. Although the Organisation’s account passwords had been
securely encrypted at the time of the Incident, it had conducted a forced logout and

password reset on every affected current Lazada account upon discovery of the Incident
to ensure that no third party could misuse the leaked passwords by logging into a current
Lazada account; and
(c)

The Incident was the Organisation’s first breach of the PDPA. To the best of

the Organisation’s knowledge and belief, the Incident was its first experience of a data
breach.

Voluntary notification

The Commission had already taken into account the Organisation’s voluntary

notification of the Incident into account in determining the quantum of the financial penalty in
the preliminary decision. Hence, this factor does not warrant a further reduction in the financial
penalty imposed.

Lack of misuse of the affected personal data

The fact that the Organisation was not aware of any misuse of the affected personal

data is neither here or there, and does not merit a further reduction in the financial penalty.
Whilst evidence of exploitative use may be a relevant factor of harm that may be relevant for
enhancing the financial penalty, the inverse is not necessarily true.

In support of its representations, the Organisation cited the case of Learnaholic Pte Ltd

[2019] SGPDPC 31 (“Learnaholic”), in which the Commissioner had taken into account the
fact that “while there was actual exfiltration of the Personal Data…there was no evidence of
further exploitation, use or disclosure of the Personal Data by the attacker”.11 It suffices to

Learnaholic at [34].

say that the Commission has explained Learnaholic in Farrer Park Hospital Pte Ltd [2022]
SGPDPC 6 at [35 to 36] as follows:

“35

In the case of Learnaholic the main factors taken into account when deciding to

reduce the preliminary financial penalty imposed were:
(a)

A reduction in the total number of affected individuals due to a recalculation of

figures; and
(b)

The benefit of doubt given to Learnaholic as to the period of time the

vulnerability in its system existed.
36

The lack of evidence of further exploitation, use or disclosure is not, ipso facto,

a factor meriting a reduction of the financial penalty. The Organisation’s
representations are not accepted as the lack of an aggravating factor (i.e. subsequent
exploitation, use or disclosure of personal data) is not in itself a mitigating factor.”
34

The explanation in Farrer Park Hospital that is cited above is equally applicable in the

present case.

Lack of antecedents

In calibrating the financial penalty in the preliminary decision, the Commission had

already taken into account the fact that this was the Organisation’s first non-compliance with
the PDPA, and no further reduction is merited. In support of its representations, the
Organisation also cited Aviva Ltd and Toh-Shi Printing Singapore Pte Ltd [2016] SGPDPC 15
(“Aviva""), where the Commission had taken into account the fact that the breach of the
Protection Obligation by the organisation was its second breach in approximately one year, and
both data breach incidents involved similar fact patterns and causes. 12 In Aviva, the
Commission had considered the organisation’s previous non-compliance as a contributory

Aviva at [38(c)].

factor that justifies an increase in the financial penalty meted as the organisation had failed to
improve its data protection practices. In contrast, the lack of antecedents in this instance means
that the Commission did not increase the financial penalty imposed on the Organisation. To be
clear, the absence of an antecedent does not, ipso facto, merit a reduction in the financial
penalty imposed.

Acceptance of the Commission’s findings

Notwithstanding the foregoing, the Commission notes that the Organisation voluntarily

accepted the Commission’s findings in the preliminary decision, that it had failed to comply
with the Protection Obligation and explicitly indicated that it would not seek to challenge these
findings. The Organisation’s voluntary acceptance of liability (even at this late stage) ought to
be reflected in the financial penalty. Had the Organisation accepted responsibility for the
Incident at an earlier stage of the investigation, it could have significantly shortened the time
for investigations and resolution of this case through the expedited breach procedure and also
benefited from greater mitigatory considerations. Nonetheless, an organisation that voluntarily
accepts responsibility for its non-compliance with the PDPA should be recognised as an
organisation that demonstrates its commitment to the Accountability Obligation and shows that
it can be responsible for the personal data in its possession or under its control.13

Having considered all the relevant factors in this case, the Commission hereby requires

the Organisation to pay a financial penalty of $72,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.

Refer to section 11(2) of the PDPA.

In view of the remedial actions already been taken by the Organisation, no further

directions need be issued to the Organisation.

YEONG ZEE KIN
DEPUTY COMMISSIONER
FOR COMMISSIONER FOR PERSONAL DATA PROTECTION

",Financial Penalty,1f2e2b94601c32c373eb88020422ba071c772e63
17,17,1,952,Directions were issued to both Shopify Commerce Singapore and Supernova to put in place a process to ensure compliance with the Transfer Limitation Obligation following a data breach incident of Shopify Inc's database.,"[""Transfer Limitation"", ""Directions"", ""Others"", ""Data Intermediary""]",2022-11-18,https://www.pdpc.gov.sg/-/media/Files/PDPC/PDF-Files/Commissions-Decisions/GD_Supernova-Pte-Ltd_06102022.pdf,Transfer Limitation,Breach of the Transfer Limitation Obligation by Shopify Commerce Singapore and Supernova,https://www.pdpc.gov.sg/all-commissions-decisions/2022/11/breach-of-the-transfer-limitation-obligation-by-shopify-commerce-singapore-and-supernova,2022-11-18,"PERSONAL DATA PROTECTION COMMISSION

[2022] SGPDPC 7

Case No: DP-2103-B8147 / DP-2206-B9935
In the matter of an investigation under
section 50(1) of the Personal Data Protection Act 2012
And

(1) Supernova Pte Ltd
(2) Shopify Commerce Singapore Pte Ltd
… Organisation

DECISION

Page 1 of 12

Supernova Pte Ltd & Anor

Yeong Zee Kin, Deputy Commissioner — Case No. DP-2103-B8147/ DP-2206-B9935

6 October 2022

Introduction

On 8 October 2020, the Personal Data Protection Commission (the

“Commission”) was notified by Supernova Pte Ltd (“SNPL”) of a data breach incident
of Shopify Inc’s database affecting the personal data of certain Singapore-based
customers (the “Incident”). The Commission commenced investigations to determine
whether the circumstances relating to the Incident disclosed any breaches of the
Personal Data Protection Act 2012 (“PDPA”).

Facts of the Case

Background

Shopify Inc (“Shopify”) is a company based in Canada that operates an e-

commerce platform for online retailers to conduct sales (the “Platform”). SNPL is an
online retailer that began using the Platform in 2018 to sell its products to customers.
Shopify provided payment processing and other services (the “Services”) to SNPL
pursuant to the Shopify Plus Agreement, executed by Shopify and SNPL on 4
December 2018. Shopify Commerce Singapore Pte Ltd (“Shopify SG”) acted as the
Page 2 of 12

Asia-Pacific data sub-processor of Shopify pursuant to the Shopify Data Processing
Addendum to the Shopify Plus Agreement, and its role was confined to collecting
customer personal data (including SNPL’s) via the Platform and transferring the data
out of Singapore to Shopify for both Purchase Processing and Platform Processing.

The Platform collected personal data from customers of its online retailers for

two broad sets of purposes. First, to facilitate billing, payment and shipping on behalf
of the Platform’s online retailers (“Purchase Processing”). Second, for Shopify’s own
commercial and administrative purposes. This mainly included the collection of
consumer personal data through the Platform’s own consumer-facing applications and
services e.g. Shop Pay (collectively, “Platform Processing”). Granted, for Platform
Processing, users of the Platform included customers of merchants who are on the
Platform, such as SNPL’s customers. Nevertheless, customer personal data was
being collected and processed by Shopify for its own purposes, and not on behalf of
merchants.

On 1 July 2019, the Shopify Plus Agreement (including the Shopify Data

Processing Addendum) was assigned to Shopify SG (the “Assignment”). At the
material time, SNPL had no knowledge of the Assignment as no notice of assignment
was required. Consequently, the relationship between the parties was reconfigured in
the following manner:
(a)

For Purchase Processing, Shopify SG became the data intermediary of
SNPL, and was responsible for processing personal data on behalf of SNPL.
Page 3 of 12

The flow of SNPL’s customer personal data did not change - Shopify SG
continued to collect SNPL’s customer personal data and transferred this to
Shopify to carry out Purchase Processing on its behalf.
(b)

For Platform Processing, Shopify SG became the data controller of the
customer personal data collected through the Platform and its customer-facing
applications, including the personal data of the customers of merchants who
use the Platform (such as SNPL). In such circumstances, personal data from
such users are collected by Shopify SG and processed for its purposes and not
on behalf of the merchants. The flow of customer personal data also did not
change, as Shopify SG continued to transfer personal data of users of its
Platform to Shopify to carry out Platform Processing.

The Incident

Between June to September 2020, two Philippines-based service contractors

of Shopify that were engaged through a third party, illegally accessed and exfiltrated
certain customer personal data stored in Shopify’s systems, which had been collected
via the Platform for Purchase Processing (the “Incident”). This included customer
personal data of SNPL. Shopify became aware of this on 15 September 2020 and
informed SNPL on 18 September 2020.

The customer personal data affected in the Incident included full names, email

addresses, billing addresses, shipping addresses, phone numbers, bank identification

Page 4 of 12

numbers, IP addresses, last 4 digits of the customer payment cards, and purchase
histories of 23,928 individuals.

Findings and Basis for Determination

Neither SNPL nor Shopify SG were responsible for the security of Shopify’s

systems in Canada holding the personal data affected in the Incident. Nevertheless,
both organisations were bound by section 26 of the PDPA.

Transfer limitation obligation under section 26 of the PDPA

Section 26(1) of the PDPA provides that an organisation shall not transfer any

personal data to a country or territory outside Singapore except in accordance with
requirements prescribed under the PDPA to ensure that organisations provide a
standard of protection to personal data so transferred that is comparable to the
protection under the PDPA (the “Transfer Limitation Obligation”). The requirements
applicable to the aforementioned transfers of personal data from SNPL and Shopify
SG to Shopify were those prescribed in Part III of the Personal Data Protection
Regulations 2014 (“PDPR 2014”)1. In particular:

(a)

Regulation 9(1)(b) of the PDPR 2014 requires an organisation that transfers
personal data to a country or territory outside of Singapore to take appropriate
steps to ensure that the recipient of the personal data is bound by legally

The PDPR 2014 governs the transfers of personal data prior to 1 February 2021. Transfers of personal data after
1 February 2021 are governed by the Personal Data Protection Regulations 2021.
Page 5 of 12

enforceable obligations to provide to the transferred personal data a standard
of protection that is at least comparable to that under the PDPA; and
(b)

Regulation 10(1)(b) and 10(1)(c) provide that such legally enforceable
obligations include may be imposed on the recipient by contract or binding
corporate rules (subject to Regulation 10(2) and 10(3) respectively).

Breach of the Transfer Limitation Obligation by SNPL

When SNPL entered into the Shopify Plus Agreement on 4 December 2018, it

was aware that by using the Platform its customer personal data would be transferred
to Shopify, which was outside Singapore, for Purchase Processing. Shopify was
SNPL’s data intermediary, whilst Shopify SG was Shopify’s data sub-processor as
explained in paragraph 2.

SNPL (as the data controller of its customers’ personal data) had been notified,

in the Shopify Plus Agreement, that its customer personal data may be transferred out
of Singapore for the purpose of Purchase Processing, and was obligated to comply
with the Transfer Limitation Obligation vis-à-vis the personal data collected by Shopify
/ Shopify SG for Purchase Processing. Section 4(3) of the PDPA provides that an
organisation shall have the same obligation under the PDPA in respect of personal
data processed on its behalf and for its purposes by a data intermediary as if the
personal data were processed by the organisation itself. Such obligations include the

Page 6 of 12

Transfer Limitation Obligation. As stated in the Commission’s Advisory Guidelines on
Key Concepts in the PDPA2:

“Considerations for organisations using data intermediaries

6.20

Section 4(3) provides that an organisation has the same obligations
under the PDPA in respect of personal data processed on its behalf by
a data intermediary as if the personal data were processed by the
organisation itself. As such, it is good practice for an organisation to
undertake an appropriate level of due diligence to assure itself that
a potential data intermediary is capable of complying with the
PDPA.

…
Overseas transfers of personal data

6.22

Where an organisation engages a data intermediary to process personal
data on its behalf and for its purposes, the organisation is responsible
for complying with the Transfer Limitation Obligation in respect of any
overseas transfer of personal data. This is regardless of whether the
personal data is transferred by the organisation to an overseas data
intermediary or transferred overseas by the data intermediary in

Advisory Guidelines on Key Concepts in the PDPA (Rev 1 October 2021)
Page 7 of 12

Singapore as part of its processing on behalf and for the purposes
of the organisation.

6.23

transferring

organisations

may

rely

data

intermediaries’ extant protection policies and practices, including
their assurances of compliance with relevant industry standards or
certification.”

(emphasis added)

The Transfer Limitation Obligation required SNPL to ensure, prior to

transferring customer personal data for processing by Shopify, that Shopify provided
a standard of protection to transferred personal data that was comparable to the
protection under the PDPA. This obligation did not abate by virtue of the Assignment
on 1 July 2019, even though SNPL claimed that it was not made aware of the
Assignment. At all times, SNPL was responsible for complying with the Transfer
Limitation Obligation for its transfer to Shopify (initially) and Shopify SG (latterly). Even
though Shopify SG assumed legal responsibility as SNPL’s data intermediary
Page 8 of 12

supposedly without informing SNPL, the flow of SNPL’s customer personal data was
not altered, as Shopify SG continued to transfer SNPL’s customer personal data
outside of Singapore (i.e. to Shopify) for Purchase Processing.

In connection with this, the onus laid with SNPL to put in place the relevant

contractual clauses to ensure the protection of its personal data to a standard
comparable to the PDPA. However, investigations revealed that SNPL did not do so.
The omission to put in place contractual clauses to ensure such comparable protection
began with the start of their commercial arrangement. SNPL stated that, in 2018, it
carried out a due diligence assessment of Shopify’s approach to data protection before
entering into the Shopify Plus Agreement and migrating its online retail activities to the
Platform (“2018 Due Diligence Exercise”). However, this assessment was
inadequate as it failed to ensure that there were binding contractual clauses requiring
personal data transferred between them to be protected to a standard comparable to
the PDPA.

Accordingly, SNPL failed to comply with the Transfer Limitation Obligation.

Breach of the Transfer Limitation Obligation by Shopify SG

For the Purchase Processing of customer personal data discussed in the

preceding paragraphs, Shopify SG acted as SNPL’s data intermediary and was thus
not bound by the Transfer Limitation Obligation.

Page 9 of 12

However, Shopify SG must also comply with the Transfer Limitation Obligation

in relation to the personal data collected for Platform Processing. This is because
Shopify SG was processing customer personal data for its own purposes, and was
thus the data controller, while Shopify is the data intermediary.

In connection with this, investigations revealed that there were no legally

binding obligations, in the form of contracts or binding corporate rules within the
Shopify group, requiring Shopify to provide PDPA-comparable protection to personal
data transferred from Shopify SG to Shopify for processing. While the Shopify Data
Processing Addendum makes references to certain data protection legislation
applicable to the European Union and the State of California, it did not cover the PDPA.
During the course of investigations, Shopify indicated that it would “be putting in place
binding corporate rules governing the transfer of merchants’ customers’ data between
group entities” and furnished a draft APAC Cross-Border Whitepaper to the
Commission. Whilst this was a step in the right direction, it did not retrospectively allow
Shopify SG to regularise its intra-group data transfers to ensure compliance with the
Transfer Limitation Obligation at the material time.

In view of the foregoing, Shopify SG failed to comply with the Transfer Limitation

Obligation in respect of Platform Processing of personal data.

The Deputy Commissioner’s Directions

In determining what directions (if any) should be given to the organisations

pursuant to section 48I of the PDPA, and/or whether the Organisation should be
Page 10 of 12

required to pay a financial penalty under section 48J of the PDPA, the factors listed at
section 48J(6) of the PDPA were considered. In particular, the Commission placed
emphasis on the fact that SNPL and Shopify SG had been highly cooperative with the
Commission’s investigations.

On 18 July 2022, SNPL made representations to the Commission requesting

for additional time to comply with the above direction. In consideration of SNPL’s
limitations as a small and medium enterprise, SNPL’s deadline to comply with the
direction is extended from 60 days to 6 months.

Having considered all the relevant factors of this case, SNPL is hereby directed

to take the following actions:
(a)

SNPL is to put in place within 6 months a process to ensure compliance

with the Transfer Limitation Obligation under section 26 of the PDPA in any
future engagement of services that may involve the processing of personal data
outside of Singapore on behalf of SNPL; and
(b)

Shopify SG is to put in place within 60 days a process to ensure

compliance with the Transfer Limitation Obligation under section 26 of the
PDPA in any future engagement of its services that may involve the processing
of personal data outside of Singapore.

Specific to SNPL’s transfer of personal data for the purpose of Purchase

Processing to Shopify in Canada, the following observations may be helpful. The
Page 11 of 12

Association of Southeast Asian Nations (“ASEAN”) adopted and endorsed the Model
Contractual Clauses (“ASEAN MCCs”), which are meant to facilitate cross-border
transfers of personal data. These provide a standard for business-to-business (B2B)
transfers that can be used by enterprises of any scale, but are especially helpful for
small and medium enterprises. When using them, businesses may adapt these
clauses as necessary for their commercial arrangements.

The Commission recognises the ASEAN MCCs as meeting the requirements

of the Transfer Limitation Obligation under the PDPA: see PDPC’s Guidance for the
Use of ASEAN Model Contractual Clauses for Cross Border Data Flows in Singapore
(published 22 January 2021). Using the ASEAN MCCs can ease B2B transfers
between Singapore and other jurisdictions such as Canada. In carrying out the
directions, SNPL may therefore wish to consider relying on and adapting, as
necessary, the ASEAN MCCs.

YEONG ZEE KIN
DEPUTY COMMISSIONER
FOR PERSONAL DATA PROTECTION

Page 12 of 12

",Directions,a460c9f6da7d242e2c26bf56c9b5bc6bd47df7e7
18,18,1,952,"A financial penalty of $58,000 was imposed on Farrer Park Hospital for failing to put in place reasonable security arrangements to protect the personal data in its possession or under its control.","[""Protection"", ""Financial Penalty"", ""Healthcare""]",2022-11-18,https://www.pdpc.gov.sg/-/media/Files/PDPC/PDF-Files/Commissions-Decisions/GD_Farrer-Park-Hospital-Pte-Ltd_15092022.pdf,Protection,Breach of the Protection Obligation by Farrer Park Hospital,https://www.pdpc.gov.sg/all-commissions-decisions/2022/11/breach-of-the-protection-obligation-by-farrer-park-hospital,2022-11-18,"PERSONAL DATA PROTECTION COMMISSION

[2022] SGPDPC 6

Case No. DP-2007-B6646

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

Farrer Park Hospital Pte Ltd
… Organisation

DECISION

Farrer Park Hospital Pte Ltd

Farrer Park Hospital Pte Ltd
Lew Chuen Hong, Commissioner — Case No. DP-2007-B6646
15 September 2022
Introduction
1

On 23 July 2020, the Personal Data Protection Commission (the

“Commission”) received a data breach notification from Farrer Park Hospital Pte Ltd
(the “Organisation”). The Organisation discovered that between 8 March 2018 and
25 October 2019, 9,271 emails had been automatically forwarded from two
employees’ (the “Employees”) Microsoft Office 365 work email accounts (the “Email
Accounts”) to a third-party’s email address (the “Third Party”), thereby disclosing the
personal data of 3,539 unique individuals (the “Incident”).
Background
2

The Organisation is a private tertiary healthcare institute that provides a range

of healthcare services. The nature of the Organisation’s operations requires its
employees to regularly handle highly sensitive personal data of past, present, and
prospective patients. At the material time, the Employees were part of the
Organisation’s marketing department which, inter alia, processes requests for the
Organisation’s medical services via email. The email requests received by the
Organisation’s marketing department contain personal data pertinent to the medical
treatment(s) requested by individuals including:
(a)

Name;

(b)

Gender;

Farrer Park Hospital Pte Ltd

(c)

Nationality;

(d)

Date of Birth;

(e)

NRIC Number (full and partial);

(f)

Passport details (including Passport numbers);

(g)

Contact number;

(h)

Photograph; and

(i)

Medical information, including the following (the “Medical Information”):
(i)

Medical Condition(s) – namely, patient’s health condition(s),

including doctor’s diagnosis, brief description of the health condition
provided by the patient or an appointment with a specialist for a specific
condition mentioned;
(ii)

Medical History – namely, more than one record of a patient’s

health condition(s).
(iii)

Medical Results/Reports – namely, documents containing a

medical procedure or analysis (for example, X-Rays).
(collectively, the “Affected Data Types”)
Security measures prior to discovery of the Incident
3

At the time of the Incident, the Organisation had implemented various IT and

data protection policies regulating the collection, use, disclosure, and protection of
personal data, including:

Farrer Park Hospital Pte Ltd

(a)

A ‘Data Protection Handbook’ to provide awareness and assistance to

its employees in complying with the Personal Data Protection Act 2012 (the
“PDPA”);
(b)

A ‘Personal Data Protection Policy for Patient Records’ to outline the

Organisation’s protocol for managing patients’ medical records as well as the
relevant retention period of medical records;
(c)

‘IT

Security

Management

Standards’

policy

detailing

the

establishment, implementation, and management of the Organisation’s
information security program to ensure the prevention, detection, containment,
and correction of security breaches;
(d)

An ‘Access Control Standards’ policy setting out the Organisation’s

standards relating to user accounts and password security settings; and
(e)

An ‘Acceptable Use Policy’ stipulating the Organisation’s rules governing

the acceptable use of its IT resources, including access to emails, websites, the
internet, and other types of organisational information, and which mandated
that user passwords be at least 8 characters long, and contain characters from
at least 3 of the below 4 categories

(i)

“English upper-case letters (e.g., A, B, C, …Z)”;

(ii)

“English lower-case letters (e.g., a, b, C, …Z)”;

(iii)

“Alphanumeric (e.g., 1, 2, 3, …9)”; and

(iv)

“Special characters) (e.g., ?, !, %, $, #)”.

The Organisation had also implemented various IT security measures and

vendor-based solutions including:
3

Farrer Park Hospital Pte Ltd

(a)

Staff training sessions on medical confidentiality, and periodic email

updates on developments to the PDPA and guidelines issued by the
Commission;
(b)

Regular phishing exercises on employees to continually inculcate

awareness on the techniques that malicious actors might deploy to undermine
the organisation’s IT security;
(c)

A cloud-based filtering service to protect the Organisation against spam,

malware, and other email threats;
(d)

Signature-based and behaviour-based endpoint protections to protect

endpoints from known and unknown malicious files;
(e)

User and entity behaviour analytics utilising deep learning algorithms to

identify anomalies based on the Organisation’s usual network traffic;
(f)

Webpage whitelisting solutions to only allow users to access permitted

sites and/or category of sites based on the Organisation’s defined policies;
(g)

Firewalls to prevent unauthorised access into FPH’s private network;

and
(h)

A network intrusion prevention system to analyse network traffic to

prevent known malicious activities from occurring within the Organisation’s
network.
5

At the time of the Incident, the work email accounts of the Organisation’s

employees were hosted on Microsoft Office 365 (“Office 365”), and the Organisation’s
employees were able to access their work email accounts through the internet via a
web-browser (i.e. web-mail). In June 2019, the Organisation implemented multi-factor
4

Farrer Park Hospital Pte Ltd

authentication (“MFA”) for all of its employees’ work email accounts as part of its
planned initiatives. The MFA implemented by the Organisation required its employees
to key in a one-time password sent to their registered mobile number when accessing
their work email accounts from a new device (the “OTP Process”). Upon successfully
accessing their work email account on that device, employees had the option of
choosing to “stay signed in” to their work email account on that authenticated device.
Where this option was chosen, employees would not be required to undergo the OTP
Process when subsequently accessing their work email accounts on that same
authenticated device.
6

The Organisation represented that the above security solutions did not detect

any anomalies and/or unusual activities in the Organisation’s email traffic before 24
October 2019.
The Incident
7

On 24 October 2019, the Organisation’s IT helpdesk received a complaint that

one of the Email Accounts was not able to send outgoing emails. In conducting checks
to address this complaint, the Organisation’s IT helpdesk discovered that Office 365
had automatically imposed restrictions on the Email Accounts. This is a security
feature of Microsoft’s Exchange Online Protection which indicated unauthorised
access to the Email Accounts. Further investigations by the Organisation confirmed
that the Email Accounts had been configured to automatically forward all incoming
emails to the Third Party. This auto-forwarding of emails occurred between 8 March
2018 to 25 October 2019 for one of the Email Accounts, and between 1 April 2018 to
25 October 2019 for the other.
8

In total, 9,271 emails were forwarded from the Email Accounts to the Third

Party. This resulted in the unintended disclosure of personal data belonging to 3,539
5

Farrer Park Hospital Pte Ltd

unique individuals, of which 1,923 unique individuals also had their Medical
Information disclosed. The Affected Data Types were disclosed in different
permutations and not all affected individuals had all of the Affected Data Types
disclosed through the various forwarded emails.
9

For completeness, the MFA and OTP Process had been not implemented at

the time when the Incident first occurred on 8 March 2018.
Remedial Measures
10

After discovering the Incident, the Organisation carried out the following

remedial measures:
(a)

Disabled the auto-forwarding feature for end-users;

(b)

Increased the frequency of internal cybersecurity training and exercises;

(c)

Implemented additional technical email and network security measures;

and
(d)

Refreshed and upgraded various of its existing network security

measures.
11

The Organisation has advised that it will by 2022, upgrade, refresh and/or

enhance its existing solutions for its:
(a)

Network security measures; and

(b)

Endpoint security measures.

Farrer Park Hospital Pte Ltd

Findings and Basis for Determination
12

In view of the circumstances of the Incident, the Commission’s investigation

focused on whether the Organisation had breached its obligation under section 24 of
the PDPA 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 “Protection
Obligation”).
13

In deciding what constitutes reasonable security arrangements and/or controls,

organisations should take into consideration the nature of the personal data in
question, as well as the impact that disclosure of that personal data might have on
affected person(s). This is a fact-specific assessment that organisations should
undertake when developing and/or implementing its security arrangements, policies,
and controls. As stated in the Commission’s Advisory on Key Concepts in the PDPA1:
“There is no ‘one size fits all’ solution for organisations to comply with the
Protection Obligation. Each organisation should consider adopting security
arrangements that are reasonable and appropriate in the circumstances, for
example, taking into consideration the nature of the personal data, the form in
which the personal data has been collected (e.g. physical or electronic) and the
possible impact to the individual concerned if an unauthorised person obtained,
modified or disposed of the personal data. For example, in the employment
context, it would be reasonable to expect a greater level of security for highly
confidential employee appraisals as compared to more general information
about the projects an employee has worked on.

1 See sections 17.2 – 17.3 of Advisory Guidelines on Key Concepts in the PDPA (Rev 1 February 2021)

Farrer Park Hospital Pte Ltd

In practice, an organisation should:
a)

design and organise its security arrangements to fit the nature of the
personal data held by the organisation and the possible harm that might
result from a security breach;

identify reliable and well-trained personnel responsible for ensuring
information security;

implement robust policies and procedures for ensuring appropriate levels
of security for personal data of varying levels of sensitivity; and

be prepared and able to respond to information security breaches
promptly and effectively.

In addition, it might be useful for organisations to undertake a risk assessment
exercise to ascertain whether their information security arrangements are
adequate. In so doing, the following factors may be considered:
a)

the size of the organisation and the amount and type of personal data it
holds;

who within the organisation has access to the personal data; and

whether the personal data is or will be held or used by a third party on
behalf of the organisation.”
[emphasis added]

Farrer Park Hospital Pte Ltd

For the reasons set out below, it is determined that the Organisation failed to

implement reasonable security arrangements to protect the personal data in the Email
Accounts from the risk of unauthorised access and disclosure.
Failure to put in place reasonable security arrangements to meet its needs
15

Where the personal data in question is sensitive and/or may cause damage to

affected individuals if compromised, organisations should implement stronger access
and security measures. The Commission has issued guidance on this issue in its
Guide to Securing Personal Data in Electronic Medium2 (the “Guide”) In particular,
paragraphs 7.3 and 7.4 of the Guide state that:
“7. 3. The strength of authentication, such as password requirements or other
mechanisms for access to personal data, should depend on the potential
damage to the individual, such as potential damage to reputation or finances, if
such personal data is compromised…
7.4

More secure authentication methods include two-factor or multi-factor

authentication. These involve the use of a combination of information that the
user knows, such as a password or PIN, and an object that only the user
possesses, such as a digital key, token or smart card, or a unique physical trait,
such as the use of fingerprints in biometric technology. The use of multi-factor
authentication increases confidence in the identity of the user accessing the
system.”
[emphasis added]

2 Guide to Securing Personal Data in Electronic Medium (revised Jan 2017)

Farrer Park Hospital Pte Ltd

The Commission’s latest Guide to Data Protection Practices for ICT Systems3

also recommends two tiers of (i) basic and (ii) enhanced data protection practices for
organisations to adopt in different circumstances. The guidance remains that larger
quantities and more sensitive personal data call for enhanced data protection
practices:
“…For organisations that hold large quantities of different types of personal data
or data that might be more sensitive to the individuals or organisations, they
should additionally implement the relevant enhanced practices suggested....
The design and implementation of these protection measures should always
take into consideration the extent of the sensitivity of the data based on the
nature of business and types of services offered.”4
17

In the present case, the Organisation ought to have implemented stronger

security arrangements, policies and/or controls to manage its marketing department’s
Office 365 work email accounts, for the following reasons:
(a)

The Organisation’s marketing department routinely (on a daily basis)
received and processed sensitive personal data, namely, the Medical
Information of past, present and prospective patients.

(b)

The volume of sensitive personal data processed by the Organisation’s
marketing department was not insignificant (1,923 individuals’ Medical
Information processed over 18 months).

3 Guide to Data Protection Practices for ICT Systems (2021)
4 Guide to Data Protection Practices for ICT Systems (2021), page 8

Farrer Park Hospital Pte Ltd

(c)

The marketing department’s Office 365 work email accounts were
accessible from the Internet (i.e. web-mail) which taken together with the
above factors, exacerbated their vulnerability to unauthorised access.

Without prescribing the specific measures that would have been appropriate for

the Organisation’s circumstances, stronger security arrangements, policies and/or
controls could have included:
(a)

Implementing enhanced access controls for the marketing department’s

web-mail access (e.g. MFA, IP address based white-listing);
(b)

Implementing policies and/or processes for the marketing department to

collect Medical Information via a more secure platform (e.g. a separate webportal);
(c)

Implementing policies and/or processes for Medical Information to be

regularly moved and purged from the marketing department’s Office 365 email
accounts, and stored in a more secure system (e.g. a non-Internet facing
medical records or customer relationship management system); and/or
(d)

Implementing policies and/or processes for Medical Information

disclosed via the marketing department’s email accounts to be better protected
(e.g. password protecting email attachments).
19

For the avoidance of doubt, it is accepted that web-mail may be an appropriate

and cost-effective way for organisations to provide their employees with out-of-office
email access, and that it may not be necessary for organisations to implement
enhanced controls to regulate the use of all types of web-mail accounts. It is incumbent
on organisations to assess whether enhanced controls should be implemented to

Farrer Park Hospital Pte Ltd

regulate the use of web-mail accounts, considering factors such as the volume and
sensitivity of the personal data processed using such accounts.
20

In the present case, while MFA was eventually implemented for the marketing

department’s Office 365 work email accounts as an enhanced access control
measure, this was unfortunately only after the Incident had occurred. Web-mail
accounts are exposed to modes of attack that may defeat or circumvent 8-character
alphanumeric password protection. Given that the marketing department was routinely
processing personal data of a sensitive nature, it was incumbent on the Organisation
to implement stronger security arrangements, policies and/or controls in conjunction
with its adoption of web-mail.
21

In the premises, the Commission finds that the Organisation breached the

Protection Obligation by failing to implement stronger security arrangements, policies
and/or controls in respect of the Email Accounts.
Risks arising from Email Auto-Forwarding
22

The automatic forwarding of emails to external domains (“Email Auto-

Forwarding”) is a known security risk. In March 2018, it was reported that the Office
of the Australian Information Commissioner was investigating a data breach incident
notified by a member of the Maersk Group involving the auto-forwarding of 50,000
emails sent to 3 employees’ accounts to external parties5. More recently, in a Private
Industry Notification dated 25 November 2020, the United States of America’s Federal
Bureau of Investigations warned that cyber-criminals have been exploiting autoforwarding rules on web-based email clients to perpetuate business email compromise

5 https://www.zdnet.com/article/oaic-received-31-notifications-in-the-first-three-weeks-of-data-breach-scheme/

Farrer Park Hospital Pte Ltd

scams and recommended, amongst other mitigation measures, that Email AutoForwarding be prohibited by default6.
23

Locally, in Singapore Medical Association [2020] SGPDPCS 13, an

unauthorised user gained access to an email account and created an email rule to
forward emails to an external email address. 137 emails were forwarded without
authorisation, resulting in the unauthorised disclosure of the personal data of 68
individuals. The danger of allowing Email Auto Forwarding is clear, but there is an
easy fix – organisations can simply disable this function and ensure that it remains
disabled.
24

In the present case, the Organisation conducted a ‘Business Impact

Assessment’ in 2013 on the use of Office 365 to assess the risks involved from the
use of corporate email and instant messaging. The Organisation also subsequently
conducted regular reviews and assessments of security risks arising from the use of
Office 365 within the Organisation. Unfortunately, these steps did not include an
assessment of the risks arising from Office 365’s default setting which allowed Email
Auto-Forwarding.
25

The Organisation, on its part, stated that it had not specifically examined

disabling the default Email Auto-Forwarding feature in Office 365 because there had
been no guidelines, standards, or benchmarks at the material time prior to the Incident
recommending disabling of or management of risks from default Email AutoForwarding. Neither had it been a common industry practice to do so prior to the
Incident. In this regard, it is noted that Microsoft only released specific guidance on

6 https://www.ic3.gov/Media/News/2020/201204.pdf

Farrer Park Hospital Pte Ltd

restricting or controlling Email Auto-Forwarding in Office 365 around July / August
20207.
26

It is recognised that Email Auto-Forwarding may be a useful function that serves

valuable needs in relation to some email accounts. The Protection Obligation requires
organisations, as part of their periodic security review, to assess the frequency and
manner of use of Email Auto-Forwarding, and to weigh and counter the attendant risks.
In particular, it is incumbent on organisations to apply their minds and make their own
assessments of the risks and implications of adopting the default settings of “out-ofthe-box” software solutions (see COURTS (Singapore) Pte Ltd [2020] SGPDPC 17 at
[14] and DS Human Resource Pte. Ltd. [2019] SGPDPC 16 at [9]).
27

On balance, and on the facts of this case, the Organisation is given the benefit

of the doubt that the lack of guidelines, standards or benchmarks at the material time
may have affected its assessment of the risks arising from the Office 365 default Email
Auto-Forwarding rule. This omission will therefore not be factored in determining the
enforcement action to be taken in this case. However, there must be no doubt that
failure to make reasonable assessment of the risks from Email Auto-Forwarding within
an organisation is breach of the Protection Obligation that would, in future cases, be
met with the appropriate enforcement action.
The Commissioner’s Preliminary Decision
28

In determining whether to impose a financial penalty on the Organisation

pursuant to section 48J(1) of the PDPA, and if so, the amount of such financial penalty,

7 See https://www.vansurksum.com/2020/08/25/microsoft-is-making-changes-related-to-automatic-email-

forwarding-for-atp-customers-here-is-what-you-need-to-know/ referencing Microsoft’s MC 218984 published July
2020 and MC220853 published August 2020. See also: https://docs.microsoft.com/en-us/microsoft365/security/office-365-security/external-email-forwarding?view=o365-worldwide

Farrer Park Hospital Pte Ltd

the factors listed at section 48J(6) of the PDPA were taken into account, as well as the
following mitigating factors:
Mitigating Factors
(a)

The Organisation took immediate remedial actions following the

Incident;
(b)

The Organisation cooperated fully with the Commission during the

investigations;
(c)

Prior to the Incident occurring, the Organisation had in place various

technical security measures, including current market solutions; and
(d)

The Organisation had conducted various data protection and

cybersecurity training for its employees.
29

The Organisation was notified of the preliminary decision by way of the

Commission’s letter dated 20 April 2022 and was invited to make representations on
the same.
Representations Made by the Organisation
30

On 6 May 2022, the Organisation made the following representations to the

Commission seeking a reduction in the amount of the financial penalty to be imposed:
(a)

The Organisation had voluntarily notified the Commission and affected

individuals of the Incident even though it was not legally obliged to do so under
the PDPA, at the material time;
(b)

There was no misuse of the affected personal data;
15

Farrer Park Hospital Pte Ltd

(c)

The Organisation took prompt remedial actions to contain and mitigate

the effects of the Incident, and prevent recurrence;
(d)

The Incident was the Organisation’s first breach of the PDPA; and

(e)

The financial penalty which the Commissioner intended to impose was

excessive in light of previous Commission decisions for similar or more serious
breaches of the PDPA.
Representations on voluntary notification and lack of antecedents
31

The Organisation represented that it voluntary notified the Commission of the

Incident despite not being legally obliged to do so, as the obligation for organisations
to notify the Commission of notifiable data breaches (as defined under s 26B of the
PDPA) only came into effect on 1 February 2022. The Organisation’s voluntary
notification of the Incident was taken into account when the Commission determined
the preliminary financial penalty, and does not merit a further reduction of the same.
32

Likewise, the Organisation’s representations that it had not committed any

breaches of the PDPA prior to the Incident are not accepted. The Organisation’s lack
of antecedents had already been taken into account in calibrating the preliminary
financial penalty.
Representations on the lack of misuse of the affected personal data
33

The Organisation represented that its private forensic expert had monitored the

Internet and dark web from 25 February 2020 to 24 April 2020 and not found any
information or data (including personal data of the affected individuals) relating to the
Incident disclosed during that period. The Organisation further stated that it had not
received any complaints from any affected individual as of the date of the
16

Farrer Park Hospital Pte Ltd

representations in relation to misuse of their personal data. The Organisation therefore
represented that no individuals had been harmed or had suffered loss as a result of
the Incident.
34

In support of its representations, the Organisation cited the case of Learnaholic

Pte Ltd [2019] SGPDPC 31 (“Learnaholic”), in which the Commissioner had taken
into account the fact that “while there was actual exfiltration of the Personal
Data…there was no evidence of further exploitation, use or disclosure of the Personal
Data by the attacker.”8
35

In the case of Learnaholic the main factors taken into account when deciding

to reduce the preliminary financial penalty imposed were:
(a)

A reduction in the total number of affected individuals due to a

recalculation of figures; and
(b)

The benefit of doubt given to Learnaholic as to the period of time the

vulnerability in its system existed.
36

The lack of evidence of further exploitation, use or disclosure is not, ipso facto,

8 Learnaholic at [34]
9 See Public Prosecutor v AOM [2011] SGHC 29 at [37] and Edwin s/o Suse Nathen v Public Prosecutor [2013]

SGHC 194 at [24] for the equivalent positions in the criminal sentencing domain.

Farrer Park Hospital Pte Ltd

Representations on the prompt remedial actions taken by the Organisation
37

The Organisation represented that the Commission had not taken into

consideration the immediate nature of the remedial action taken to contain the
Incident, as well as the success of the immediate post-Incident remediation and
recovery efforts. The Organisation further stated that it had not suffered any breaches
of the same nature since the Incident, which was proof of the effectiveness of its
remedial actions.
38

The Organisation’s prompt remedial actions were already taken into account in

determining the preliminary financial penalty. However, this is weighed against the
lengthy time period during which the Email Auto-Forwarding took place (March 2018
– October 2019) and long delay in detecting the breach in the first place.
Representations on previous Commission decisions
39

The Organisation cited two previous Commission decisions in support of its

representations that the intended financial penalty was excessive for similar or more
serious breaches of the PDPA. These two cases are The National Kidney Foundation
[2021] SGPDPC 10 (“NKF”) and Singapore Medical Association [2020] SGPDPCS 13
(“SMA”).
NKF
40

The breach in NKF concerned a hacker who had gained access to the work

email account of one of NKF’s employees, thereby gaining access to 23,145 emails
containing the personal data of approximately 500 individuals, including patients,
employees, and third parties. The Organisation submitted that both cases were similar
in the following areas:
18

Farrer Park Hospital Pte Ltd

(a)

Types of personal data involved (i.e. sensitive medical information);

(b)

Similar root causes and nature of the incidents;

(c)

Failure by the organisations to implement 2FA/MFA for web-mail access

at the time of the incidents;

(d)

Increased data protection awareness as remedial measures; and

(e)

Mitigating factors.

The Organisation distinguished NKF and submitted that a lower financial

penalty was justified in this case for the following reasons:
(a)

The Incident was less egregious than NKF because NKF involved:
(i)

an additional category of sensitive personal data (bank account

information), apart from just medical information; and
(ii)

the hacker synchronising and downloading contents of the

compromised email account; while no such synchronising or further use
of the compromised email accounts was detected in the Incident;
(b)

The

Organisation

had

carried

out

far

substantial

and

comprehensive remedial measures than NKF; and
(c)

The number of individuals affected by the Incident was not significantly

higher than the number of individuals affected by the NKF incident.
42

The Organisation’s representations are not accepted for the following reasons:

Farrer Park Hospital Pte Ltd

(a)

In NKF only 8 patients’ medical information was compromised, as

opposed to the disclosure of 1,923 individuals’ medical information due to the
Incident. The breach in the Incident was therefore of a much larger magnitude.
(b)

The length of time that the breach went undetected was much longer in

the Incident – the first email account was compromised in early 2018 and went
undetected by the Organisation until October 2019, which was more than a
year. This is much longer than the time it took for detection of the breach in
NKF, where the hacker obtained access around 14 May 2020 and NKF
discovered the breach on 17 May 2020.
(c)

The number of individuals affected by the Incident is more than 7 times

higher (500 in NKF as opposed to 3,539 in the Incident). The two incidents thus
cannot be considered in the same bracket of egregiousness.
SMA
43

The breach in SMA concerned unauthorised access to an email account by

brute force attack, and the subsequent forwarding of 137 emails containing the
personal data of 68 individuals to an external email address. The Organisation
submitted that both cases were similar in the following areas:

(a)

Types of personal data involved; and

(b)

Similar root causes and nature of the incidents.

The Organisation distinguished SMA and submitted that a lower financial

penalty was justified because the Organisation had implemented more comprehensive
security measures than SMA. In particular, the Organisation highlighted its own

Farrer Park Hospital Pte Ltd

periodic changes of email account passwords and limit of the number of failed login
attempts, in contrast with SMA which did not implement these measures.
45

The Organisation’s representations are not accepted as the volume and

sensitivity of personal data affected in the Incident was much higher than in SMA:
(a)

The number of affected individuals in the Incident was 3,539; many times

higher than the 68 affected individuals in SMA.
(b)

The following categories of sensitive information were disclosed in the

Incident but not in SMA: passport details, photographs, contact numbers, and
notably, specific medical information. As a hospital, the Organisation must be
held to a higher standard with regard to safeguarding medical information.
46

Notwithstanding the foregoing, the Commission notes that the Organisation

voluntarily accepted the Commission’s findings in the preliminary decision, that it had
failed to comply with the Protection Obligation and explicitly indicated what it would
not seek to challenge these findings. The Organisation’s voluntary acceptance of
liability (even at this late stage) is accepted to have some mitigating weight, meriting
a small reduction in the financial penalty. Had the Organisation accepted responsibility
for the Incident at an earlier stage of the investigation, this may have merited a larger
discount. An organisation that voluntarily accepts responsibility for its non-compliance
with the PDPA is an organisation that demonstrates its commitment to the
Accountability Obligation and shows that it can be responsible for the personal data in
its possession or under its control.10
47

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

hereby requires the Organisation to pay a financial penalty of $58,000 within 30 days
10 S 11(2) of the PDPA

Farrer Park Hospital Pte Ltd

from the date of the relevant notice accompanying this decision, 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.
48

No further directions are necessary on account of the remedial measures

already taken by the Organisation.

YEONG ZEE KIN
DEPUTY COMMISSIONER
FOR COMMISSIONER FOR PERSONAL DATA PROTECTION

",Financial Penalty,0022595df88e4b744c91519d483b5cc7416a2511
19,19,1,952,QCP Capital was found not in breach of the PDPA in relation to an incident whereby threat actor(s) exfiltrated personal data via unauthorised access to an employee's account.,"[""Protection"", ""Not in Breach"", ""Finance and Insurance""]",2022-10-25,https://www.pdpc.gov.sg/-/media/Files/PDPC/PDF-Files/Commissions-Decisions/Decision---QCP-Capital-Pte-Ltd---16092022-(002).pdf,Protection,No Breach of the Protection Obligation by QCP Capital,https://www.pdpc.gov.sg/all-commissions-decisions/2022/10/no-breach-of-the-protection-obligation-by-qcp-capital,2022-10-25,"PERSONAL DATA PROTECTION COMMISSION

[2022] SGPDPCS 16

Case No. DP-2108-B8816

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

And

QCP Capital Pte Ltd

SUMMARY OF THE DECISION

1. On 30 August 2021, QCP Capital Pte Ltd (the “Organisation”) notified the
Personal Data Protection Commission (the “Commission”) of a personal data
breach that had occurred through an unauthorised access to employee
accounts and exfiltration of customer personal data (the “Incident”).

2. As a result of the Incident, the personal data of 675 individuals was exfiltrated.
The personal data affected includes name, NRIC number, date of birth,
address, passport scan, passport number, photograph, email address, phone
number, Telegram and WeChat ID, whitelisted address and trading records
(which included the account balances, buy/sell/settlement activities).

Page 1 of 3

3. The Organisation engaged an external cybersecurity company, Blackpanda Pte
Ltd, to investigate the Incident. Its investigations found that the threat actor(s)
had accessed two accounts, belonging to one employee, to gain unauthorised
access to the Organisation systems and subsequently exfiltrated of personal
data.

4. Investigations revealed that the Organisation had provided and made
reasonable security arrangements to protect personal data in its possession
and/or control in relation to the Incident. The Organisation also had an internal
monitoring system in place which allowed the Organisation to detect, escalate
the anomalous transaction, flag and suspend the trading account affected.

5. Following the Incident, the Organisation took prompt and extensive remedial
action to mitigate the effects of the Incident and enhance the overall robustness
of its security measures. This included notifying the affected individuals,
layering access controls and introducing mandatory hardware key access
authentication.

6. In view of the above, the Deputy Commissioner for Personal Data Protection is
satisfied that the Organisation was in compliance with its Protection Obligation
under section 24 of the PDPA and cannot be held liable for the unauthorised
access by the threat actor(s) involved. No enforcement action therefore needs
to be taken in relation to the Incident.

Page 2 of 3

Page 3 of 3

",Not in Breach,b38af202b30c4ef6f100bb2255281e89e63fdcc6
20,20,1,952,"A financial penalty of $26,000 was imposed on Cognita Asia Holdings for failing to put in place reasonable security arrangements to protect the personal data in its possession from a ransomware attack.","[""Protection"", ""Financial Penalty"", ""Education"", ""Ransomware"", ""Schools""]",2022-10-25,https://www.pdpc.gov.sg/-/media/Files/PDPC/PDF-Files/Commissions-Decisions/Decision---Cognita-Asia-Holdings-Pte-Ltd---09062022.pdf,Protection,Breach of the Protection Obligation by Cognita Asia Holdings,https://www.pdpc.gov.sg/all-commissions-decisions/2022/10/breach-of-the-protection-obligation-by-cognita-asia-holdings,2022-10-25,"PERSONAL DATA PROTECTION COMMISSION

[2022] SGPDPCS 14

Case No. DP-2106-B8484

In the matter of an investigation under section 50(1) of the
Personal Data Protection Act 2012
And
Cognita Asia Holdings Pte Ltd

SUMMARY OF THE DECISION

1. On 16 June 2021, Cognita Asia Holdings Pte Ltd (the ""Organisation"") notified the
Personal Data Protection Commission (the “Commission”) of a ransomware
attack on 13 June 2021. The ransomware incident (the ""Incident"") affected the
servers of three schools run by the Organisation.

2. The ransomware encrypted the personal data of 1,260 individuals, of which 1,195
are students. The personal data included copies of identification/passport page,
salaries of the affected employees and the bank account details necessary for the
crediting of salaries.

Page 1 of 5

3. The Organisation’s internal investigations found that the threat actor gained initial
entry to one of the school's network in April 2021 through a VPN session. The VPN
logs showed no brute-force entry attempts, suggesting the use of compromised
administrator account credentials. Investigations disclosed that between 8 and 12
June 2021, the threat actor gained broad network access and deployed the
encrypting ransomware.

4. The Organisation requested that this matter proceed via the Expedited Decision
Breach Procedure, which the Commission acceded to. To this end, the
Organisation voluntarily and unequivocally admitted to the facts set out in this
decision. It also admitted to a breach of section 24 of the Personal Data Protection
Act (the ""PDPA""), also referred to as the Protection Obligation.

5. At the time of the Incident, even though the Organisation employed VPN, the
Organisation’s existing configuration of VPN required merely a username and
password for authentication. However, the personal data collected and processed
by the Organisation included copies of the photographic identification documents
of students as well as salary and bank account information of employees. In view
of the nature of personal data that it holds, the Organisation needed a higher level
of security and stronger access control for its administrator accounts, such as multifactor authentication for VPN connection to its administrator accounts to protect
such personal data.

Page 2 of 5

6. The Organisation also failed to have reasonable password policies or ensure
compliance with their existing password policies. The Organisation did not enforce
their password policies in the following areas:
(i) Although the Organisation's password policy specified a minimum
requirement of 10 characters, in practice the requirement that was enforced by
their IT systems was only 8 characters; and
(ii) Its password policy of requiring the default password to be changed after the
first usage was not enforced.

7. The Commission's Handbook on ""How to Guard Against Common Types of Data
Breaches"", which is complemented by the ""Checklists to Guard Against Common
Type of Data Breaches"", has identified poor management of accounts and
passwords as one of the five common causes and types of data breaches.
Organisations must adopt, implement, and enforce a strong password policy as a
necessary measure of data protection.

8. Finally, the Organisation also failed to ensure that personal data protection training
was conducted for its staff. In this regard, the Commission wishes to reiterate that
staff training in personal data protection is an important and necessary component
of the Protection Obligation of an organisation.

9. In light of the above, the Organisation is found to have breached section 24 of the
PDPA.
Page 3 of 5

10. The Commission acknowledged that, the Organisation informed the relevant
stakeholders of the Incident and implemented real time threat monitoring and Deep
and Dark Web monitoring for potentially exposed personal data.

11. The Organisation also undertook remedial actions to mitigate the effects of the
Incident and improve the robustness of its security measures. This included the
engagement of a cybersecurity expert to investigate the cause of the Incident and
working together with the said expert to enact a Remediation Plan.

12. The Remediation Plan included measures such as, enforcing multi-factor
authentication of all staff accounts, enhancing the password requirements for
administrator accounts, and increasing the frequency of security reviews and cyber
security trainings for its staff.

13. The Organisation also conducted security awareness webinars and offered a 12
months’ personal identity monitoring services to all the staff and parents (who can
sign up on behalf of the affected students) of these three schools.

14. The Commission’s decision to require payment of a financial penalty, and on the
quantum of the penalty, took into account sections 48J(1) and 48J(6) of the PDPA,
and all the relevant circumstances of the case. This included the Organisation's
admission of breach of the Protection Obligation, which the Commission considers
Page 4 of 5

is a significant mitigating factor. Having considered all the facts of this case, the
Commissioner hereby requires the Organisation to pay a financial penalty of
S$26,000.

15. The Organisation must make payment of the financial penalty within 30 days from
the date of the notice accompanying this decision, 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.

16. In view of the remedial actions taken by the Organisation, the Commission will not
issue any directions under section 48I of the PDPA.

",Financial Penalty,2bb79bfdd23b06a8855ff98de1a352eac57e3ebd
21,21,1,952,"A financial penalty of $60,000 was imposed on MyRepublic for failing to put in place reasonable security arrangements to protect the personal data in its possession.","[""Protection"", ""Financial Penalty"", ""Information and Communications""]",2022-09-15,https://www.pdpc.gov.sg/-/media/Files/PDPC/PDF-Files/Commissions-Decisions/Decision---MyRepublic-Ltd---05082022.pdf,Protection,Breach of the Protection Obligation by MyRepublic,https://www.pdpc.gov.sg/all-commissions-decisions/2022/09/breach-of-the-protection-obligation-by-myrepublic,2022-09-15,"PERSONAL DATA PROTECTION COMMISSION

[2022] SGPDPC 5

Case No. DP-2108-B8814

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

And

MyRepublic Limited
… Organisation

DECISION

Page 1 of 11

MyRepublic Limited
Lew Chuen Hong, Commissioner — Case No. DP-2108-B8814
5 August 2022

Introduction
1

On 29 August 2021, the Personal Data Protection Commission (“the

Commission”) received information that MyRepublic Limited (“the Organisation”)
had been the subject of a cyber incident. On 1 September 2021, the Organisation
informed the Commission that a threat actor had exfiltrated and deleted customers’
personal data from its IT systems (the “Incident”).
2

The Organisation requested for the investigation to be handled under the

Commission’s Expedited Breach Decision procedure. In this regard, the Organisation
voluntarily provided and admitted to the facts set out below, and admitted that it had
failed to implement reasonable security arrangements to protect the personal data
accessed and exfiltrated in the Incident in breach of section 24 of the Personal Data
Protection Act 2012 (“PDPA”).
Facts of the Case
3

The Organisation is incorporated in Singapore, and is a telecommunications

operator that holds a Facilities-Based Operations licence (“FBO Licence”) under
Section 5 of the Telecommunications Act 1999.
4

At the time of the Incident, the Organisation accepted customer orders for

mobile services through its Mobile Order Portal (“Portal”). The Organisation’s
customers who applied for mobile services would submit their customer identity
verification and number portability documents (the “KYC documents”) through the
Portal, and the Portal would store the KYC documents in a bucket (the “Bucket”) on
cloud-storage procured from Amazon Web Services (“AWS”).
Page 2 of 11

While the Bucket was publicly accessible, its access was restricted through the

use of an access key (the “Access Key”) in the Amazon Identity and Access
Management feature. The Access Key could only be used to access the Bucket and
no other AWS accounts, systems or bucket used by the Organisation. The Access Key
was stored in the source code of the Portal to facilitate the transfer of the KYC
documents submitted through the Portal, to the Bucket.
6

On 29 August 2021 (SGT), the Organisation became aware that an external

actor had accessed and exfiltrated the KYC documents submitted by customers
applying for mobile services. The Organisation received an email from the external
actor threatening to publish the downloaded customer data unless a ransom was paid.
7

Following the Incident, the Organisation engaged an IT forensic investigator

(among others) to assist in its incident response. Investigations revealed that the
external actor had utilised the Access Key to access the Bucket. Fortunately, the
compromised Access Key could not be used by the external actor to access the
Organisation’s other AWS accounts, systems or buckets. However, an unusually large
volume of data had been downloaded from the Bucket before it was deleted.
8

While the Organisation was unable to determine with certainty how the external

actor had obtained the Access Key, the Organisation determined that the external
actor had likely obtained the Access Key through two vulnerabilities identified within
the Portal, namely:
(a)

The disclosure of the Access Key in the Portal’s functionality which

displayed technical information; and
(b)

The disclosure of the Access Key in the Portal’s source code repository

which was available to all the Organisation’s developers, one of whom may
have inadvertently disclosed the Access Key.

Page 3 of 11

The personal data of 79,388 of the Organisation’s customers was accessed

and exfiltrated in the Incident, comprising the following:
(a)

For 75,026 Singapore citizens and permanent residents: Scanned
copies of both sides of NRIC and work pass cards, which included the
customer’s full name, address, date of birth, gender, race, place of birth,
full NRIC number, photograph, thumbprint, date of issuance of card, (for
Employment Passes only) employer and nationality, and (for
Dependant’s Passes only) nationality;

(b)

For 4,362 foreigners: Scanned copies of residential address documents
such as utility bill, tenancy agreement or insurance policy, which included
the customer’s name, address and other information; and

(c)

For 3,631 customers porting an existing mobile service: porting form
which included the customer’s full name and mobile phone number.

(collectively, the “Customer Data”).
Remedial actions
10

Following the Incident, as part of remedial actions, the Organisation:
(a)

Revoked the Access Key and issued a replacement key for the Bucket;

(b)

Removed environment configuration files from the Organisation’s Portal

that exposed the Access Key;
(c)

Reviewed activities across all accounts and buckets to ensure that the

compromise was isolated to a single bucket;
(d)

Restricted access to buckets to specific IP addresses through a block-

all-with exception policy;

Page 4 of 11

(e)

Enabled version control on buckets that were not previously

controlled/managed;
(f)

Reviewed to ensure all buckets are private and in line with AWS’ best

practices;
(g)

Reviewed to ensure all access keys are rotated;

(h)

Consolidated all AWS accounts with central monitoring enabled;

(i)

Cleaned up DNS registry across the Organisation’s IT landscape;

(j)

Issued a notification to the affected customers, recommending actions

to minimise the risks of identify fraud and social engineering, and offering the
affected customers six months of complimentary credit monitoring services;
(k)

Conducted dark web monitoring from 3 September 2021 to 3 October

2021 to verify whether the exfiltrated data have been published; and
(l)

Commissioned

the

development

programme

security

improvements for the Organisation’s systems in order to reduce the risk of
security incidents.
Findings and Basis for Determination
Whether the Organisation had contravened the Protection Obligation
11

Section 24 of the Personal Data Protection Act 2012 (“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 “Protection
Obligation”). The Organisation is required under the Protection Obligation to
implement reasonable security arrangements to prevent the risk of unauthorised
disclosure of the Customer Data, notwithstanding that the data was hosted on a
Page 5 of 11

vendor’s cloud service. This is because the Organisation retains control over such
data. In Commeasure Pte Ltd [2021] SGPDPC 11 (“Commeasure”) at [11], the
Commission found that even though a vendor was responsible for the security of the
cloud infrastructure that it provided to the organisation, the organisation bore ultimate
responsibility under the Protection Obligation for making reasonable security
arrangements to protect all the customers’ data under its control.
12

The reasonableness of the Organisation’s security arrangements to protect the

Customer Data would be assessed having regard to the volume and sensitivity of such
personal data. As stated in the Commission’s Advisory Guidelines on Key Concepts
in the Personal Data Protection Act (revised 1 October 2021) (“Advisory Guidelines”)
at [17.3], an organisation should design and organise its security arrangements to fit
the nature of the personal data held by the organisation and the possible harm that
might result from a security breach, and implement robust policies and procedures for
ensuring appropriate levels of security for personal data of varying levels of sensitivity.
13

In the course of its business, the Organisation collected and retained copies of

its customers’ KYC documents such as NRICs and work passes, which contained their
Customer Data, in compliance with its FBO Licence.1 At the time of the Incident, the
Organisation had in its control a high volume of sensitive personal data:
(a)

High volume of Customer Data: At the time of the Incident, the

Organisation had in its control the Customer Data of almost 80,000 individuals.
(b)

Sensitivity of Customer Data: The Customer Data included the

customers’ full NRIC numbers, photographs, thumbprints, and dates of
issuance of their NRIC cards. The sensitivity of such information is heightened

1 Under its FBO Licence, the Organisation is required to (i) maintain a register containing records of its

customers, including the customers’ identity number such as NRIC number, (ii) make and keep a
photocopy of its customers’ NRIC, passport or employment pass as evidence of the customers’ identity,
and (iii) keep the register of the customers for at least 12 months from the date of termination of its
services to the customers (among others).
Page 6 of 11

and there is an increased risk, for example, of identity theft, as the information
could enable access to other services provided by the Government.
14

Accordingly, the Organisation should have implemented stronger security

measures to protect the Customer Data.
15

For the reasons set out below, the Organisation failed to put in place such

reasonable security arrangements to protect the Customer Data and was determined
to be in breach of the Protection Obligation (as also admitted by the Organisation). In
particular, the Organisation failed to implement sufficiently robust processes to
manage the Access Key, and also failed to implement reasonable security controls for
its AWS environment.
Failure to implement sufficiently robust processes to manage Access Key
16

The Organisation’s Protection Obligation required it to protect the Access Key,

which allowed access to the Customer Data in the Bucket. As stated in Commeasure
at [12], AWS has, in its “Reference Guide – AWS security credentials” (“AWS
Reference Guide”), advised users to protect the access keys as “anyone who has the
access keys for your AWS account root user has unrestricted access to all resources
in your AWS account”.2
17

However, the Organisation failed to implement sufficiently robust processes to

protect the Access Key.
18

The Organisation informed the Commission that the Access Key could be

disclosed through the Portal’s functionality to display technical information, at
https://mobile.myrepublic.com.sg/php-info. The functionality, known as “PHP Info”, is
a standard function of the PHP programming environment and helps programmers to
understand the configuration of the environment. The “PHP Info” function is invoked
https://docs.aws.amazon.com/general/latest/gr/aws-access-keys-best-practices.html – see “Best
practices for managing AWS access keys” (last accessed on 5 August 2022).
Page 7 of 11
2

by executing a PHP script file. Thereafter, if the php-info URL is accessed, the browser
will display the Portal’s operating system environment variable values. These values
included the Access Key, which was used by the Portal to access and transfer
documents submitted by customers through the Portal to the Bucket. This was a
significant vulnerability as anyone who knew or could guess the php-info URL could
obtain the Access Key and use it to access the Customer Data in the Bucket. The
Organisation also determined that this was the most likely way in which the external
actor had obtained the Access Key. The Organisation should not have left the Access
Key publicly accessible through the php-info URL. Instead, the Organisation could
have disabled the “PHP Info” function or moved the Access Key from the Portal’s
system environment variables to configuration files available only to authorised
parties.
19

Further, the Organisation informed the Commission that the Access Key was

embedded in the Portal’s source code available to all the Organisation’s developers
via the source code repository. This was another way through which the external actor
could have obtained the Access Key or one of the developers with access could have
inadvertently disclosed it. The Commission has held in Commeasure at [12] that
embedding AWS access keys into the source code of applications poses a clear
security risk. In the AWS Reference Guide, AWS has likewise cautioned users not to
“embed access keys directly into code”. The Organisation could have stored the
Access Key in a file that is separate from the source code and secured with separate
access controls, or it could have utilised third party solutions for the management of
access keys.
20

In addition, the Access Key was captured in the clear in mobile order application

log files made available to employees, including external developers and engineers,
who did not require such information for their functions. If the Organisation wanted to
store credentials such as the Access Key in its log files (e.g. for development
purposes), it should have implemented reasonable security measures such as a log
file redaction mechanism to prevent disclosure of such credentials.
Page 8 of 11

In view of the above, the Organisation was found in breach of the Protection

Obligation for its failure to implement sufficiently robust processes to manage the
Access Key.
Failure to implement reasonable security controls for AWS environment
22

Apart from the Organisation’s failures in its management of the Access Key, the

Organisation also failed to implement reasonable security controls for its AWS
environment.
23

The Commission had stated in the Guide to Data Protection by Design for ICT

Systems (2021) (“Guide”) that as a basic practice, organisations should “[e]nsure that
files containing personal data are not accidentally made available on a website or
through a web application”, and “avoid storing personal data in public folders” (at page
20). In the “Amazon Simple Storage Service – User Guide”, AWS has similarly advised
its users that “[u]nless [they] explicitly require anyone on the internet to be able to read
or write to [their] S3 bucket, [they] should ensure that [their] S3 bucket is not public”.3
24

However, as stated at [5] above, the Bucket was publicly accessible. This

significantly increased the risk profile of the Bucket as external actors could find the
Bucket and thereafter access, exfiltrate and delete the Customer Data in the Bucket,
which is what occurred in the Incident. Given the high volume and sensitivity of the
Customer Data stored in the Bucket, the Bucket should not have been made publicly
available. This is especially if the Bucket was meant to interact only with the Portal for
customers to upload KYC documents for retrieval by the Organisation’s back-office
systems.
25

The Commission had stated in the Guide that organisations should put in place

ICT controls to manage data protection risks, including setting appropriate access

https://docs.aws.amazon.com/AmazonS3/latest/userguide/security-best-practices.html
– see
“Amazon S3 Preventative Security Best Practices” (last accessed on 5 August 2022).
Page 9 of 11
3

control rules, access rights, and restrictions for specific user roles (at pages 9 and 15).
Access to the Bucket should therefore have been restricted to only authorised
applications or users. In this case, the Organisation sought to restrict access to the
Bucket through the use of the Access Key, but it turned out to be ineffective because
of the Organisation's handling and inadvertent disclosure of the Access Key, as stated
above. The Organisation could also have considered layering its defences, and could
have supplemented the Access Key with a “block-all but” exception policy that allows
only specific IP addresses to access the Bucket, as implemented by the Organisation
after the Incident.
26

Accordingly, the Organisation was found to be in breach of the Protection

Obligation for failing to implement reasonable security controls for its AWS
environment.
The Commissioner’s Directions
27

In determining whether to impose a financial penalty on the Organisation

pursuant to section 48J(1) of the PDPA, and the amount of any such financial penalty,
the matters set out at section 48J(1) and the factors listed at section 48J(6) of the
PDPA were taken into account, as well as the following mitigating factors:
Mitigating Factors
(a)

The Organisation took prompt and effective remedial actions, including

notifying the affected individuals; and
(b)
28

The Organisation was cooperative during investigations.

The Commission also considered the Organisation’s voluntary acceptance of

liability for the Incident.

Page 10 of 11

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

hereby requires the Organisation to pay a financial penalty of $60,000 within 30 days
from the date of the relevant notice accompanying this decision, 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.
30

No further directions are necessary on account of the remedial measures

already taken by the Organisation.

YEONG ZEE KIN
DEPUTY COMMISSIONER
FOR COMMISSIONER FOR PERSONAL DATA PROTECTION

Page 11 of 11

",Financial Penalty,281b38e59a842f8bbcce33f312e6d5fdca027752
22,22,1,952,"Directions were issued to Budgetcars to put in place appropriate contractual provisions, conduct a security audit of its technical and administrative arrangements for the security and maintenance of its website and rectify any security gaps identified in the audit report. This is pursuant to a data breach incident where personal data could be accessed by changing a few digits of the tracking ID.","[""Protection"", ""Directions"", ""Transport and Storage""]",2022-08-11,https://www.pdpc.gov.sg/-/media/Files/PDPC/PDF-Files/Commissions-Decisions/Decision---Budgetcars-Pte-Ltd---06072022.pdf,Protection,Breach of the Protection Obligation by Budgetcars,https://www.pdpc.gov.sg/all-commissions-decisions/2022/07/breach-of-the-protection-obligation-by-budgetcars,2022-08-11,"PERSONAL DATA PROTECTION COMMISSION

[2022] SGPDPCS 13
Case No. DP-2108-B8798
In the matter of an investigation under section 50(1) of the
Personal Data Protection Act 2012
And
Budgetcars Pte. Ltd.

SUMMARY OF THE DECISION

1. On 25 August 2021, the Personal Data Protection Commission (the
“Commission”) received a complaint that the delivery tracking function (the
“Tracking Function Page”) on the website of Budgetcars Pte Ltd (the
“Organisation”) could be used to gain access to the personal data belonging to
another individual. By changing a few digits of a Tracking ID, the complainant could
access the personal data of another individual (the “Incident”).

2. The Organisation is a logistics company delivering parcels to customers
(“Customers”) on behalf of retailers (“Retailers”).

3. The personal data of 44,357 individuals had been at risk of unauthorised access.
The datasets comprised name, address, contact number and photographs of their
signatures.

4. The Tracking Function Page was set up in December 2020 to allow Retailers and
Customers to (i) keep track of the delivery status of their parcels; and (ii) confirm
the identity of individuals to collect parcels on their behalf (where applicable). The
Tracking IDs were generated by Retailers and comprised either sequential or nonsequential numbers. Although generated by Retailers, the Organisation adopted
the Tracking IDs for use on its own Tracking Function Page that allowed their
customers to track their deliveries, which would disclose personal data listed
above. The Protection Obligation therefore required the Organisation to ensure that
there were reasonable access controls in its use of the Tracking IDs for giving
access to an individual’s personal data.

5. The risk of unauthorised access to personal data from altering numerical
references, both sequential and non-sequential, have featured in the published
decisions of the Commission in Re Fu Kwee Kitchen Catering Services [2016]
SGPDPC 14, and more recently, in Re Ninja Logistics Pte. Ltd. [2019] SGPDPC
39. Insecure direct object reference has long been a well-known security risk to
personal data. The Organisation failed to have reasonable access control to the
affected individuals’ personal data when it simply adopted Tracking IDs generated
by the Retailers without factoring in this risk.

6. The Organisation also admitted that it did not have in place a process to protect
personal data through proper safeguards by archiving personal data relating to a
completed delivery order after a reasonable period of time has lapsed. To reduce
the risk of access to personal data through frontend applications, they should be
removed and archived within a reasonable time. The Organisation’s failure to do

so resulted in more personal data at risk in the Incident than should have been the
case.

7. In the circumstances, the Organisation is found to be in breach of section 24 of the
PDPA.

8. Upon being notified by the Commission of the Incident, the Organisation took the
following remedial measures after the Incident:
a. Removed all personal data from the Tracking Function Page;
b. Engaged its IT solutions provider to re-examine management of the Tracking
Function Page;
c. Post-delivery expiry of Tracking ID after 14 days; and
d. Implemented checks to prevent sequential Tracking IDs from being uploaded
onto the Tracking Function Page.

9. The Commission accepted the Organisation’s request for this matter to be handled
under the Commission’s expedited breach decision procedure. This meant that the
Organisation voluntarily provided and unequivocally admitted to the facts set out in
this decision. The Organisation also admitted that it was in breach of section 24 of
the Personal Data Protection Act (the “PDPA”).

10. In Re Ninja Logistics Pte. Ltd. cited above, the organisation had been aware of the
risk from manipulation of Tracking IDs. However, a counter-measure which the
organisation initially introduced was abandoned due to operational issues and was
not replaced. This resulted in a significantly larger dataset (>1.2 million) that was
exposed to the risk of unauthorised access over a period of close to 2 years. In

comparison, the number of affected individuals in the present case was lower as
the Organisation was only handling deliveries for a few Retailers at the time of the
Incident.

11. Having considered the circumstances set out above and the factors listed in section
48J(6) of the PDPA, including (i) the Organisation’s upfront voluntary admission of
liability; and (ii) the prompt remedial action undertaken by the Organisation, the
Commission considered that it would be appropriate not to require the payment of
a financial penalty but to direct the Organisation to do the following:
a. To put in place the appropriate contractual provisions to set out the obligations
and responsibilities of both the data controller and data intermediary to protect
the Organisation’s personal data, and the parties’ respective roles in protecting
the personal data;
b. To engage qualified security service provider to conduct a thorough security
audit of its technical and administrative arrangements for the security and
maintenance of its website that contains personal data in the Organisation’s
possession or control;
c. Provide the full security audit report to the Commission, no later than 60 days
from the date of the issue of this direction;
d. Rectify any security gaps identified in the security audit report, review and
update its personal data protection policies as applicable within 60 days from
the date the security audit report is provided; and
e. Inform the Commission within 1 week of completion of rectification and
implementation in response to the security audit report.

The following is the provision of the Personal Data Protection Act 2012 cited in the
above summary:
Protection of personal data
24. An organisation shall protect personal data in its possession or under its control
by making reasonable security arrangements to prevent –
(a) unauthorised access, collection, use, disclosure, copying, modification, disposal or
similar risks; and
(b) the loss of any storage medium or device on which personal data is stored.

",Directions,f58b11a86b70faf2534d0dbe08ee7f22ddbeaeb9
23,23,1,952,Directions were issued to Crawfort to conduct a security audit of its technical and administrative arrangements for its AWS S3 environment and rectify any security gaps identified in the audit report. This is pursuant to a data breach incident where Crawfort's customer database were offered for sale in the dark web.,"[""Protection"", ""Directions"", ""Finance and Insurance""]",2022-07-14,https://www.pdpc.gov.sg/-/media/Files/PDPC/PDF-Files/Commissions-Decisions/Decision---Crawfort-Pte-Ltd---070622.pdf,Protection,Breach of the Protection Obligation by Crawfort,https://www.pdpc.gov.sg/all-commissions-decisions/2022/07/breach-of-the-protection-obligation-by-crawfort,2022-07-14,"PERSONAL DATA PROTECTION COMMISSION

Case No. DP-2106-B8446

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

And

Crawfort Pte. Ltd.

SUMMARY OF THE DECISION

1. On 9 June 2021, Crawfort Pte. Ltd. (the “Organisation”) notified the Personal
Data Protection Commission (the “Commission”) of the sale of the
Organisation’s customer data on the dark web (the “Incident”).

2. The personal data of 5,421 customers were affected. The datasets affected
comprised NRIC images (front and back), PDF copies of loan contract
(containing all the information in the NRIC, age, email address, contact number
and loan amount) and PDF copies of income document (payslip, CPF
statements or IRAS Notice of Assessment).

3. The Organisation engaged external cyber security teams to investigate the
Incident. The investigation identified an opened S3 server port in the
Organisation’s AWS environment as the cause of the Incident.

4. The Organisation explained that it had opened the S3 server port for one week
during a data migration exercise sometime on or about 15 April 2020 for
business continuity purposes. On 3 April 2020, the Singapore government had
announced that the country will enter into a Circuit Breaker to contain the
spread of COVID-19. All non-essential workplaces, including the Organisation,
had to be closed from 7 April 2020. In order to continue its business, the
Organisation had to pivot its operations so as to allow its staff to work from
home and its customers to make loan applications remotely. Within a very short
period, the Organisation had to carry out the data migration exercise and as a
result, overlooked conducting a risk assessment prior to conducting the data
migration exercise.

5. The opened S3 server port connected directly to the S3 server hosting the S3
buckets, which contained the affected personal data. The open remote port
enabled attempts to connect to the Organisation’s AWS environment from the
internet. Furthermore, the S3 bucket containing the affected personal data was
publicly accessible due to a misconfiguration of the S3 bucket. As a result, the
threat actor was able to gain access to the publicly accessible S3 bucket during
the one-week period.
2

6. The Organisation the following remedial measures after the Incident:
a. Reset and reconfigured all whitelisted IPs to AWS server;
b. Reset and reconfigured all VPNs;
c. Limited the whitelisted IP addresses to its web portal;
d. Conducted a penetration test;
e. Monitored the dark web to ensure that data was not circulated;
f. Engaged independent cyber security consultant to carry out investigation,
study the IT infrastructure and propose improvements to their systems; and
g. Notified affected individuals.

7. The Commission accepted the Organisation’s request for this matter to be
handled under the Commission’s expedited breach decision procedure. This
meant that the Organisation had voluntarily provided and unequivocally
admitted to the facts set out in this decision. The Organisation also admitted
that it was in breach of section 24 of the Personal Data Protection Act (the
“PDPA”).

8. The Organisation admitted that it failed to conduct a reasonable risk
assessment before carrying out the data migration exercise. There was no
access control to the S3 bucket containing the affected personal data during
the week-long migration exercise. This, coupled with the open port, allowed the
threat actor to gain access to the affected personal data.

9. In the circumstances, the Organisation is found to be in breach of section 24 of
the PDPA.

10. Having considered the circumstances set out above and the factors listed in
section 48J(6) of the PDPA, including (i) the Organisation’s upfront voluntary
admission of liability which significantly reduced the time and resources
required for investigations; and (ii) the prompt remedial actions undertaken by
the Organisation, the Commission considered that it would be most appropriate
in lieu of imposing a financial penalty, to direct the Organisation to comply with
the following:
a. To engage qualified security service provider to conduct a thorough security
audit of its technical and administrative arrangements for the security and
maintenance of its AWS S3 environment that contains personal data in the
Organisation’s possession or control;
b. Provide the full security audit report to the Commission, no later than 60
days from the date of the issue of this direction;
c. Rectify any security gaps identified in the security audit report, review and
update its personal data protection policies as applicable within 60 days
from the date the security audit report is provided; and
d. Inform the Commission within 1 week of completion of rectification and
implementation in response to the security audit report.

",Directions,e2755a8249f833e1c234b8532991f2dc6896ee30
24,24,1,952,"A financial penalty of $10,000 was imposed on Audio House for failing to put in place reasonable security arrangements to protect the personal data in its possession from a ransomware attack.","[""Protection"", ""Financial Penalty"", ""Wholesale and Retail Trade"", ""Ransomware""]",2022-07-14,https://www.pdpc.gov.sg/-/media/Files/PDPC/PDF-Files/Commissions-Decisions/Decision---Audio-House-Marketing-Pte-Ltd---27052022.pdf,Protection,Breach of the Protection Obligation by Audio House,https://www.pdpc.gov.sg/all-commissions-decisions/2022/07/breach-of-the-protection-obligation-by-audio-house,2022-07-14,"PERSONAL DATA PROTECTION COMMISSION

Case No. DP-2106-B8421

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

And

Audio House Marketing Pte Ltd

SUMMARY OF THE DECISION

1. On 1 June 2021, Audio House Marketing Pte Ltd (the “Organisation”) notified the
Personal Data Protection Commission (the “Commission”) of a ransomware
affecting its customer database (the “Incident”). Approximately 98,000
individuals’ names, addresses, email addresses and telephone numbers, in the
nature of contact information, were affected.

2. The Organisation subsequently requested for this matter to be handled under the
Commission’s expedited breach decision procedure. This means that the
Organisation voluntarily provided and unequivocally admitted to the facts set out in

this decision; and admitted that it was in breach of section 24 of the Personal Data
Protection Act (the “PDPA”).

3. The Organisation’s internal investigations revealed that PHP files used to develop
a web application on the Organisation’s website contained vulnerabilities that
allowed the threat actor to carry out a SQL injection attack. The Organisation
admitted that it is possible that the vulnerabilities in the PHP files had existed since
April 2017, when its website was first launched. Further, even though the
Organisation had conducted pre-launch tests prior to the launch of its website, the
Organisation admitted that it failed to identify and detect the existing vulnerabilities
in the PHP files.

4. SQL injection attacks are well-known vulnerabilities: see “Top Ten” list of the Open
Web Application Security Project (OWASP). The Commission has consistently
advised organisations to take the necessary precautions to guard against the risk
of injection attacks (see para. 15.3 of the Commission’s Guide to Securing
Personal Data in Electronic Medium, published on 8 May 2015, and revised on 20
January 2017). We note that apart from conducting functionality testing of features
such as the shopping cart and payment on its website, the Organisation did not
conduct any vulnerability scanning and assessment that would have provided a
reasonable opportunity to discover the vulnerabilities in the PHP files that were
eventually exploited in the Incident.

5. Compounding the above, the Organisation also did not conduct reasonable
periodic security review. A reasonable periodic security review would include

vulnerability scanning and assessments, which would have offered the
Organisation the opportunity to detect any vulnerabilities that were not detected
during the pre-launch tests, or any vulnerabilities that may have arisen since.

6. Periodic security reviews is also a practice that the Commission has consistently
advised organisations to adopt. In our Checklists to Guard against Common Types
of Data Breaches, the Commission highlighted that conducting a periodic security
review is a basic practice that all organisations ought to embrace. This is also
reiterated in para. 6.1(a) of the Commission’s Guide to Securing Personal Data in
Electronic Medium where we stated that it was a good practice for organisations to
“conduct regular ICT security audits, scans and tests to detect vulnerabilities and
non-compliance with organizational standards”, and Table 13(f) of the same Guide
where we encouraged organisations to perform web application scanning and
source code analysis to help detect common web vulnerabilities, in particular,
those identified in the “Top Ten” list of the OWASP, which includes SQL injection
attacks.

7. With the use of IT comes the responsibility for data security in IT systems. We urge
organisations who may be unable to conduct such security reviews on their own to
engage the necessary expertise from the professionals.

8. Having said that, we note that the Organisation’s website was built by a company,
which the Organisation’s main IT vendor had engaged on the Organisation’s
behalf. The Organisation did not have any contract with the company that
developed the website. As a result, the Organisation failed to stipulate clear job

specifications or any data protection requirements on the company that developed
its website. There was also an absence of any data protection requirements in the
Organisation’s contract with its main IT vendor, who it relied upon to manage and
maintain its IT systems. The Commission’s published decisions1 have emphasized
that organisations engaging IT vendors should – a) stipulate personal data
protection requirements on the vendors, b) make clear the job specifications,
especially where they include security maintenance and software updates, and,
last but not least, c) exercise reasonable oversight over the vendor responsible for
the technical capabilities of the organisation so as to offer adequate protection to
the types of personal data that may be affected by the engagement of the vendor.
In cases where sub-contracting is contemplated, the Organisation should have
identified requirements in its main contract that it requires its main IT vendor to
impose similar obligations on and exercise adequate oversight over its subcontractor.

9. In light of the above, the Organisation is found to have breached the Protection
Obligation under section 24(a) of the PDPA.

10. In deciding the appropriate outcome in this case, the Commission considered the
Organisation’s cooperation throughout the investigation, the Organisation’s
voluntary admission of breach of the Protection Obligation, and the prompt
remediation actions taken. This included disabling the use of its website on the
same day of the Incident, reformatting of its webserver, adding security against
SQL injections and the implementation of vulnerable assessment and penetration

See Jigyasa [2020] SGPDPC 9 and Civil Service Club [2020] SGPDPC 15
4

testing. We note that the Organisation managed to restore all the personal data
affected without loss, thereby minimizing any disruptions to its operations.

11. Having considered the circumstances set out above and the factors listed at
section 48J(6) of the PDPA, the Deputy Commissioner for Personal Data
Protection hereby finds the Organisation in breach and directs the Organisation to
pay a financial penalty of S$10,000 within 30 days from the notice accompanying
date of this decision, failing which interest at the rate specified in the Rules of Court
in respect of judgement debts shall accrue and be payable on the outstanding
amount of such financial penalty until the financial penalty is paid in full.

12. In view of the remedial actions taken by the Organisation, no directions under
section 48I are necessary.

The following is the provision of the Personal Data Protection Act 2012 cited in the
above summary:
Protection of Personal Data
24. An organisation shall protect personal data in its possession or under its control
by making reasonable security arrangements to prevent –
(a) unauthorized access, collection, use, disclosure, copying, modification,
disposal or similar risks; and
(b) the loss of any storage medium or device on which personal data is stored.

",Financial Penalty,2506fbb092f33a10a99d72428ada09a55ade6c6b
25,25,1,952,"A financial penalty of $12,000 was imposed on Terra Systems for failing to put in place reasonable security arrangements to protect the personal data of individuals in its customer relationship management portal in Re Terra Systems Pte Ltd [2021] SGPDPC 7. An application for reconsideration was filed against the decision in Re Terra Systems Pte Ltd [2021] SGPCPC 7. Upon review and careful consideration of the application, the Commissioner had decided to affirm the finding of the breach of section 24 of the PDPA as set out in the decision and the financial penalty in the Reconsideration Decision.","[""Protection"", ""Financial Penalty"", ""Information and Communications""]",2022-07-14,https://www.pdpc.gov.sg/-/media/Files/PDPC/PDF-Files/Commissions-Decisions/Decision---Terra-Systems-Pte-Ltd----06082021.pdf,Protection,Breach of the Protection Obligation by Terra Systems,https://www.pdpc.gov.sg/all-commissions-decisions/2022/07/breach-of-the-protection-obligation-by-terra-systems,2022-07-14,"PERSONAL DATA PROTECTION COMMISSION

[2021] SGPDPC 7

Case No DP-2007-B6670

In the matter of an investigation under section 50(1)
of the Personal Data Protection Act 2012
And
Terra Systems Pte. Ltd.
… Organisation

DECISION

Terra Systems Pte. Ltd.
[2021] SGPDPC 7

Lew Chuen Hong, Commissioner — Case No. DP-2007-B6670
6 August 2021

Introduction
1

On 14 July 2020 and 21 July 2020, a customer relationship management portal (“the

Portal”) owned and operated by Terra Systems Pte Ltd (the “Organisation”) containing the
personal data of persons served with “Stay-Home Notices” 1 (“SHNs”) was accessed and
modified without the Organisation’s authorisation (the “Incident”).
2

On 27 July 2020, the Singapore Police Force notified the Personal Data Protection

Commission (“Commission”) of the Incident, and the Commission commenced its own
investigations thereafter.
Background
3

The Organisation is in the business of providing communication solutions and services,

including call centre services, to businesses in Singapore and the region. On 17 June 2020, the
Organisation was awarded a government contract to provide call centre services to help verify
the whereabouts of persons serving SHNs (“the Call Centre”).
4

To facilitate the operations of the Call Centre, the Immigration and Checkpoints

Authority (“ICA”) provided the Organisation with a daily spreadsheet containing the personal
data of persons serving SHNs, including their:
(a)

Name

(b)

Last 4 digits of NRIC;

Legal notices issued under the Infectious Diseases Act (Cap 137) requiring a person to remain at their place of
residence or at a Stay-Home Notice Dedicated Facility at all times for a stipulated period

(c)

Gender;

(d)

Contact Number;

(e)

Last Day of SHN;

(f)

Address where SHN was served; and

(g)

COVID-19 Test Appointment dates

(collectively, the “SHN Data”)
5

The Organisation created the Portal for the purposes of its internal administration of the

Call Centre. On account of the movement restrictions in force at the time owing to the COVID19 pandemic, the Portal was designed to be accessible by the Organisation’s staff from home
via the Internet.
6

Users in the Organisation were granted different levels of access to the Portal:
(a)

Directors and managers were assigned unique user IDs and passwords and were

able to view all cases in the Portal.
(b)

Team leaders were also assigned unique user IDs and passwords and were able

to view all cases assigned to agents in their teams.
(c)

Agents (i.e. the persons actually contacting the persons serving SHNs) were

temporary staff assigned simple user IDs based on their respective teams (e.g. the user
ID “D03” referred to agent number 3 in team D). Agents were also given a common
daily password which was shared with them during a morning Zoom briefing by the
Organisation’s management.
7

Agents logged in to the Portal were only able to view the cases assigned to them, and

type in remarks in a specific “remarks” column after a case had been attended to. At the end of
each day, the SHN Data would be submitted to ICA with the agents’ remarks, and all data in
the Portal would be purged.
8

On 14 July 2020, crude remarks were found to have been inserted in the remarks field

of 3 cases in the Portal. The two agents assigned to deal with those cases and their team leader
2

denied inserting the remarks. The Organisation changed the common password for the day and
began informing agents of the new daily common password via Whatsapp instead. The
Organisation also implemented a web server logging function to track the actions of users
logged in to the Portal. This functionality had not enabled previously.
9

On 21 July 2020, another crude remark was inserted in the remarks field of a case

assigned to one of the same agents. The Organisation traced the action to an unauthorized user
based on the IP address from which the Portal was accessed and reported the Incident to the
police.
10

The perpetrator of the Incident is believed to be a disgruntled ex-employee of the

Organisation. On 14 July 2020, the perpetrator is believed to have obtained the daily common
password by attending the morning Zoom briefing, after obtaining the login details for the
morning Zoom briefing from other employees. On 21 July 2020, the perpetrator is believed to
have directly obtained the daily common password from another employee who was unaware
that his employment had been terminated.
11

After being notified of the Incident, the Organisation took the following remedial

actions on ICA’s instructions:
(a)

The practice of using common passwords was ceased, and agents were required

to adopt unique passwords,
(b)

Agents were assigned unique user IDs which were different from the generic

IDs based on their teams;
(c)

Two-factor authentication was implemented for all access to the Portal; and

(d)

Security scanning was performed on the Portal.

Findings and Basis for Determination
Whether the Organisation had contravened section 24 of the PDPA
12

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
(“Protection Obligation”).
13

For the reasons set out below, the Organisation is found to have failed to implement

reasonable security arrangements to protect the SHN Data from the risk of unauthorised access.
Failure to implement reasonable IT access controls
14

Firstly, the Organisation failed to implement reasonable IT access controls to the SHN

Data in the Portal. The use of (i) generic user IDs for agents which were known to all or
guessable, and (ii) a daily common password for all agents, were poor practices that posed
serious security risks.
15

Employing simple user IDs and a common password defeated the purpose of

segregating agents’ access to cases in the Portal. Any agent could have accessed another agent’s
cases by using that agent’s commonly known or guessable user ID and the common password.
While there is only evidence that the perpetrator in this case accessed and modified the SHN
Data of 4 persons (based on the distinct cases in the Portal in which crude remarks were
inserted), the perpetrator could have accessed the SHN Data of all 125 persons assigned to his
former team.
16

The Incident could have been prevented had all agents been assigned unique user IDs

and passwords.
Failure to implement policies to mitigate risks from using common password
17

Secondly, the Organisation failed to implement adequate policies to mitigate the risks

created by the use of a daily common password to access the Portal. Having made the decision
to use a common password for access to the Portal, the Organisation attempted to identify the
associated risks and adopt suitable policies and practices. Unfortunately, their efforts proved
to be inadequate
18

The Organisation clearly recognised some risks associated with use of a common

password – this was why they adopted the practice of changing the common password daily.
However, it was foreseeable that agents would ask each other for the daily common password,
4

for example, when they had forgotten the password or had missed the morning Zoom briefing.
An agent may not have suspected that anything was amiss if someone they believed to be
another agent had asked them for the daily password or the login details for the morning Zoom
briefing. This risk was exacerbated by the fact that all of the agents were temporary staff and
that personnel changes were to be expected. Thus, on both 14 July 2020 and 21 July 2020, the
perpetrator is believed to have obtained either the login details for the morning Zoom briefing
or the common daily password itself from the Organisation’s employees.
19

If the Organisation had properly appreciated this risk, it could have implemented

policies (i) prohibiting agents from disseminating or sharing the daily common password under
any circumstances, and (ii) requiring any agents who missed the daily morning Zoom briefings
to obtain the daily common passwords directly from their team leaders or managers, who would
be better placed to verify the requestor’s employment status. Admittedly, such policies would
have been difficult to police. However, they would have at least reduced the risk of disclosure
of the common password to unauthorised persons.
20

It is acknowledged that the Organisation was under pressure to operationalise the Call

Centre and Portal within a short timeframe to support ICA’s operations in the midst of the
COVID-19 pandemic. Even so, its failures to implement reasonable access controls gave rise
to the present Incident. The Organisation failed to make reasonable security arrangements to
protect the SHN Data from unauthorised access and modification in breach of its obligation
under section 24 of the PDPA.
The Commissioner’s Decision
21

In determining whether any directions should be imposed on the Organisation under

The SHN Data was sensitive in nature considering the climate of the COVID-

19 pandemic and unauthorised disclosure could have caused the individuals to
experience discrimination or social stigma;
5

Mitigating Factors

(b)

The Organisation had to operationalise the Portal under urgent circumstances;

(c)

The Organisation took prompt remedial actions following the Incident; and

(d)

The Organisation was cooperative during the investigations.

Having considered the above factors and circumstances, the Commissioner

preliminarily determined that a financial penalty of $12,000 would be imposed in respect of
the Organisation’s negligent contravention of the Protection Obligation. On 22 April 2021, the
Organisation was notified of the Commissioner’s preliminary decision, including the full
findings set out above, and given 14 days to make written representations.
The Organisation’s representations
23

On 7 May 2021, the Organisation submitted written representations requesting that it

be issued a warning in lieu of a financial penalty. While the Organisation did not dispute that
it had breached the Protection Obligation, it claimed that the circumstances of its case were
similar or less egregious to recent enforcement decisions of the Commission in which warnings
had been given to organisations for breaches of the Protection Obligation2.
24

According to the Organisation, unlike in the precedent cases cited:
(a)

Only 4 individuals’ personal data was affected in the Incident (i.e. a very low

number);
(b)

The personal data affected (i.e. the SHN Data) was not sensitive;

(c)

There was no exfiltration or public exposure of the SHN Data;

(d)

Prompt remedial measures were implemented within 48 hours with no loss of

personal data; and

Chan Brothers Travel Pte Ltd (DP-1905-B3936, Summary of the Decision); Horizon Fast Ferry Pte Ltd (DP1912-B5464, Summary of the Decision); MRI Diagnostics Pte Ltd (DP-1811-B2975, Summary of the
Decision); Water+Plants Lab Pte Ltd (DP-2004-B6182, Summary of the Decision); R.I.S.E Aerospace Pte Ltd
(DP-2007-B6832, Summary of the Decision); Everlast Projects Pte Ltd [2020] SGPDPC 20; Chapel of Christ
the Redeemer (DP-2010-B7132, Summary of the Decision); St Joseph’s Institution International Ltd (DP-2010B7196, Summary of the Decision); and ACCA Singapore Pte Ltd (DP-2011-B7385, Summary of the Decision).

(e)

Reports were voluntarily made to the authorities (including ICA and the police)

and the Organisation was not held to ransom or complained about by any members of
the public.
25

The Organisation also claimed that unauthorised disclosure of the SHN Data would not

have caused the affected individuals to experience discrimination or social stigma. The
Organisation claimed that it was normal for anyone entering Singapore at the time to be subject
to an SHN, and that many persons had even publicised this fact. With reference to the precedent
cases cited, the Organisation claimed that the disclosure of (i) students’ grades, (ii) church
members’ marital statuses, and (iii) employees’ salaries, carried a greater risk of the affected
persons experiencing discrimination or social stigma in the relevant circumstances.
26

After careful consideration, the Organisation’s representations were rejected.

While there may have been facts in specific domains of the precedent cases which

appeared either similar or more egregious than the Incident, this did not mean that the
Organisation was deserving of a warning. Every case is decided based on an evaluation of all
the relevant facts and circumstances, and in a manner that is fair and appropriate for the
particular organisation investigated.
28

There are two main distinguishing factors which justifies the imposition of a financial

penalty in the Organisation’s case compared to the precedent cases cited:
(a)

First, contrary to the Organisation’s representations, the SHN Data is considered

to have been sensitive at the material time, during the early days of the COVID-19
pandemic when there was uncertainty about its virulence and high levels of public
health concerns. The Organisation was engaged to help administer the SHN regime as
part of a national effort to manage the pandemic. While the SHN Data did not include
positive diagnoses for COVID-19, the fact of being subject to an SHN nevertheless
denoted risk of exposure to the virus. The fact that the Incident occurred in July 2020
just after the end of “circuit breaker” measures and when public concern was high, was
important context.
(b)

Second, within the same context of a national health emergency, the

Organisation’s level of culpability was much higher than that of the organisations in
7

the cited precedents. The Organisation employed very poor access control measures
which were easily circumvented by an unsophisticated actor. A common password was
used by over 50 users and shared over an unsecure platform, with no audit trail. While
the Organisation’s representations focused solely on the alleged harm caused by the
Incident and the remedial steps taken afterwards, the extent of the Organisation’s
negligence in the Incident was also an important factor which justified the imposition
of a financial penalty in its case.
29

For completeness, the Organisation’s representations also failed to account that the

personal data of 125 individuals was exposed to the risk of unauthorised access in the Incident,
notwithstanding that only 4 records had been modified. In any event, the fact that the Incident
only affected a limited number of persons has been taken into account in calibrating the
quantum of the financial penalty imposed. Other factors raised by the Organisation such as the
prompt implementation of remedial measures and voluntary reporting have similarly been
accounted for.
30

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

requires the Organisation to pay a financial penalty of $12,000 within 30 days from the date of
the relevant notice accompanying this decision, 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.
31

In view of the remedial actions that have already been taken by the Organisation, no

other directions are necessary.

YEONG ZEE KIN
DEPUTY COMMISSIONER
FOR COMMISSIONER FOR PERSONAL DATA PROTECTION

",Financial Penalty,72732e0dda0822fd38160244a8fdf6eca77d9bca
26,26,1,952,"A financial penalty of $67,000 was imposed on Quoine for failing to put in place reasonable security arrangements to protect the personal data in its possession.","[""Protection"", ""Financial Penalty"", ""Finance and Insurance""]",2022-07-14,https://www.pdpc.gov.sg/-/media/Files/PDPC/PDF-Files/Commissions-Decisions/Decision---Quoine-Pte-Ltd---08022022.pdf,Protection,Breach of the Protection Obligation by Quoine,https://www.pdpc.gov.sg/all-commissions-decisions/2022/07/breach-of-the-protection-obligation-by-quoine,2022-07-14,"PERSONAL DATA PROTECTION COMMISSION

[2022] SGPDPC 2

Case No. DP-2011-B7409 / DP-2011-B7421

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

And

Quoine Pte Ltd
… Organisation

DECISION

Quoine Pte Ltd
[2022] SGPDPC 2

Lew Chuen Hong, Commissioner — Case Nos. DP-2011-B7409 / DP-2011-B7421
8 February 2022

Introduction
1

On 17 November 2020, Quoine Pte Ltd (“the Organisation”) informed the

Personal Data Protection Commission (“the Commission”) that its domain manager
had transferred control of its domain hosting account to an external actor, who
accessed and exfiltrated the personal data of 652,564 of its customers (“the
Incident”). The Commission subsequently received a complaint from an individual
believed to have been affected in the Incident.
2

The Organisation requested for the investigation to be handled under the

Commission’s Expedited Breach Decision procedure. In this regard, the Organisation
voluntarily provided and admitted to the facts set out below, and admitted that it had
failed to implement reasonable security arrangements to protect the personal data
accessed and exfiltrated in the Incident in breach of Section 24 of the Personal Data
Protection Act 2012 (“PDPA”).
Facts of the Case
3

The Organisation is a company incorporated and based in Singapore, and a

subsidiary of Liquid Group Inc., which is incorporated in Japan. The Organisation
operates a global cryptocurrency exchange under the “Liquid” brand, and has
customers around the world.
4

At the time of the Incident, the Organisation’s back-end IT infrastructure

included the following:

(a)

Its vendor-procured cloud computing platform (“Cloud Platform”) which

it used to run its cryptocurrency exchange platform, and which hosted its cloud
computing database; and
(b)

Its additional cloud computing storage procured from another vendor,

which it used to store documents such as Know-Your-Client (“KYC”)
documents.
5

The Organisation also engaged a third party domain name registrar (“the

Domain Provider”) to register and host the Organisation’s domain (@quoine.com
domain). A domain name registrar allows a party to purchase and register domain
names, where the domain name translates to a public address of the party’s servers
(e.g. webserver, email server) for routing purposes.
6

On 13 November 2020, a staff member of the Organisation received an email

from the Domain Provider stating that changes had been made to the settings of the
Organisation’s domain hosting account with the Domain Provider (@quoine.com
domain) (“Domain Hosting Account”). Staff members also received password reset
emails for accounts on the Organisation’s other file-sharing and office productivity
services. As the Organisation had not requested for the changes, the Organisation
followed up with the Domain Provider, who acknowledged that the Organisation’s
email accounts on its domain with the Domain Provider were no longer routed to the
Organisation.
7

Investigations revealed that:
(a)

As a result of social engineering attacks on employees of the Domain

Provider, an employee of the Domain Provider incorrectly transferred control of
the Organisation’s Domain Hosting Account to an external actor. This allowed
the external actor to change the registered email address on the Organisation’s
Domain Hosting Account and subsequently effect a password reset on the
account to take control of the Domain Hosting Account.

(b)

Control of the Domain Hosting Account allowed the external actor to

know the number of servers using the domain name, and the IP addresses of
these servers.
(c)

With control of the Domain Hosting Account, the external actor changed

the servers to which the Organisation’s email traffic was directed (i.e. via
changes to the Organisation’s mail exchanger (MX) records), from the email
servers used by the Organisation to the external actor’s email servers. This
redirected all of the Organisation’s emails to the external actor’s email servers.
According to the Organisation, this impacted the Organisation’s security
monitoring capability as many alerts and notifications, which were distributed
via email, were consequently redirected to the external actor’s email servers.
The Organisation’s staff members continued to receive emails notifying of
changes to the settings of the Domain Hosting Account (referred to at [6] above)
on alternative recovery options that had been set up.
(d)

Having redirected the Organisation’s emails on the Organisation’s

domain (@quoine.com domain) to itself, the external actor then initiated
password resets for several of the services tied to the Domain Hosting Account.
The external actor successfully carried out a password reset on an account
(“DevOps Account”) used by the Organisation for automation tasks and to run
codes throughout the day which was not used interactively by humans.
(e)

The external actor then used the DevOps Account’s newly reset

credentials to access the Organisation’s Cloud Platform, which hosted API
keys/token to the Organisation’s database hosted within the Cloud Platform as
well as a separate cloud computing storage database (collectively, the
“Databases”). The external actor thereby gained credentials to the Databases,
and accessed and exfiltrated personal data stored in the Databases.
8

The personal data of 652,564 of the Organisation’s customers was accessed

and exfiltrated in the Incident, comprising the following:
(a)

First name and surname;

(b)

Address;

(c)

Email address;

(d)

Telephone number (optional);

(e)

Photo-image of documents provided by 362,035 customers for KYC
purposes before 13 October 2018, namely, NRIC number, passport
number or other identification documents, proof of address document,
and photograph;

(f)

Financial information of Japanese customers of Quoine Corporation, a
Japanese company related to the Organisation;

(g)

Transaction information: fiat deposits and crypto withdrawals, and a
2018 record of balances prior to the launch of the current “Liquid
Exchange”; and

(h)

For customers depositing and withdrawing fiat currencies: Bank account
and other information, namely, name of the bank, account number and
name of the account holder.

(collectively, the “Customer Data”).
Remedial actions
9

Following the Incident, as part of remedial actions, the Organisation:
(a)

Notified its customers to alert them of the Incident, advised them of

actions to take to secure their accounts, and recommended precautionary
measures to monitor any suspicious activities which may have suggested
improper use of their personal information;
(b)

Moved its domains to a more robust service provider that offered

Enterprise level support, strong access control (username, password and
mandatory two-factor authentication (“2FA”)) and roles-based access controls;
(c)

Migrated the entire Liquid exchange to a different vendor-provided cloud

computing platform, with additional improvements made in the interactions
between the Organisation’s service accounts and the system; and

(d)

Strengthened the use of the DevOps Account, and imposed IP whitelist

restrictions where appropriate.
10

The Organisation is also evaluating other services to further harden its

infrastructure, including cloud security configuration tools.
Findings and Basis for Determination
Whether the Organisation had contravened the Protection Obligation
11

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

As a preliminary point, while the Organisation had engaged the Domain

Provider to host the Organisation’s domain, the Domain Provider did not process any
personal data on behalf of the Organisation and was not the Organisation’s data
intermediary. Due consideration is given to the fact that the initial breach occurred with
the Domain Provider. The basis of the Commission’s decision is that the Protection
Obligation in respect of the Customer Data was borne solely by the Organisation and
there were failures in respect of how it secured access to its Cloud Platform, leading
to the unauthorised disclosure of Customer Data.
13

The Commission has repeatedly highlighted that an organisation should design

and organise its security arrangements to fit the nature of the personal data held by
the organisation and the possible harm that might result from a security breach, and
implement robust policies and procedures for ensuring appropriate levels of security
for personal data of varying levels of sensitivity (see the Commission’s Advisory
Guidelines on Key Concepts in the Personal Data Protection Act (revised 1 October
2021) (“Advisory Guidelines”) at [17.3]; see also Credit Counselling Singapore
[2017] SGPDPC 18 at [25] and PeopleSearch Pte. Ltd. [2019] SGPDPC 47 at [10]).
As stated in the Commission’s Advisory Guidelines at [17.5], measures that an
organisation can use to protect personal data include adopting appropriate access

controls (e.g. considering stronger authentication measures where appropriate) and
installing appropriate computer security software and using suitable computer security
settings.
14

Considering the Organisation’s business as a global cryptocurrency exchange

that regularly deals with a large volume of sensitive personal data of a financial nature,
the Organisation’s overall data protection and cybersecurity posture should have been
very much heightened. The Organisation was in possession of 822,096 individuals’
Customer Data, including photo-image of documents and other information provided
by 362,035 customers for KYC purposes, cryptocurrency transactions and bank
account information. Consequently, the Organisation is required under the Protection
Obligation to have implemented strong security arrangements to protect the Customer
Data held in its Databases.
15

In the present case, the Organisation has admitted that it failed to implement

reasonable security arrangements to protect the Customer Data, and that it was in
breach of the Protection Obligation. In particular, the Organisation (i) failed to review
and assess the DevOps Account’s security implications and risks, and (ii) failed to
implement reasonable ICT controls for the DevOps Account.
Failure to review and assess the DevOps Account’s security implications and risks
16

The Commission has highlighted in previous decisions the importance of

carrying out correctly-scoped periodic security reviews, so as to detect vulnerabilities
and assess security implications and risks, and to ensure that reasonable security
arrangements have been put in place to protect personal data in an organisation’s
database.
17

In WTS Automotive Services Pte. Ltd. [2018] SGPDPC 26 (“WTS”), the

Commission highlighted the importance of conducting regular reviews to ensure that
websites collecting personal data and electronic databases storing personal data have
“reasonable security arrangements to prevent unauthorised access, collection, use,
disclosure, copying, modification, disposal or similar risks”, as personal data of
individuals may be exposed if a website or database in which it is stored contains
vulnerabilities (at [18] of WTS).

Likewise, in Commeasure Pte Ltd [2021] SGPDPC 11 (“Commeasure”), the

organisation had neglected to include the affected application package and access
key (which the threat actor had used to access and exfiltrate personal data in the
organisation’s cloud database) in its inventory of IT assets in production, which had
resulted in their omission from its periodic security reviews. The organisation was
found in breach of the Protection Obligation on this basis, as the vulnerability could
otherwise have been discovered and the incident could have been prevented (at [16][17] of Commeasure). While the organisation explained that its failure to implement
sufficiently robust processes to manage its inventory of infrastructure access keys was
attributable to the high turnover of its employees from the time of its inception to the
discovery of the incident, this was unacceptable because the organisation’s
responsibility to protect personal data in its control or possession ought not to have
been subjected to staff movement or appointment (at [13] of Commeasure).
19

As held in Chan Brothers Travel Pte Ltd [2020] SGPDPCS 11 (“Chan

Brothers”), organisations must be aware of security implications of software features
of their IT systems, so as to configure the security settings to enable effective
protection of personal data stored in the IT systems (at [5] of Chan Brothers).
20

During the investigations, the Organisation admitted that its periodic reviews of

access “failed to acknowledge this weakness as they incorrectly focussed on accounts
used interactively by humans only, and not the automation bot accounts”. According
to the Organisation, until the Incident, it was not aware of the vulnerability and
weakness in access control to the DevOps Account, which did not have 2FA enabled.
Accordingly, similar to the facts of Commeasure as set out above, although the
Organisation had conducted periodic security reviews, these security reviews were
improperly scoped, and failed to identify this vulnerability present in the DevOps
Account.
21

The Organisation also admitted that the DevOps Account “was created without

sufficient due diligence being given to the entire security risk profile of this type of
account”, and “[t]his is a vulnerability that had not been adequately assessed by
implementing alternative security measures to address the lack of 2FA”.

The Organisation had therefore failed to review and assess the security

implications and risks arising from the DevOps Account and its lack of 2FA. The
Organisation’s failures in this regard were especially egregious, given that the DevOps
Account had privileged access to the Organisation’s Cloud Platform containing API
keys/tokens to the Databases, and consequently, the Customer Data stored in the
Databases. If the Organisation had included the DevOps Account in its security review
and detected the vulnerabilities in the lack of 2FA, and/or had assessed and
appreciated the security implications and risks arising from the DevOps Account and
its lack of 2FA, it could have taken reasonable security measures to mitigate these
security risks and to configure the security settings to enable effective protection of the
Customer Data in the Databases.
23

The Organisation informed the Commission during the investigations that its

current staff were not aware of the reasons for the DevOps Account’s set-up and
security arrangements, as the DevOps Account had been created “at some time in the
past (so legacy)”. The Organisation explained that there had been internal personnel
movement. For instance, its DevOps team had initially been based in and managed
out of Tokyo, then Quoine Vietnam. However, by mid-2020, the DevOps Tokyo team
was no longer with the Organisation, and the DevOps team that remained was in
Quoine Vietnam. While we are sympathetic to the challenges presented as a result of
any personnel movements, it was incumbent on the Organisation to implement the
necessary systems and processes to ensure that critical information about its IT
systems, including legacy systems, survived the turnover of its staff. As the
Commission has also held in Commeasure and stated above, an organisation’s
responsibility to protect personal data in its control or possession ought not to have
been subjected to staff movement or appointment.
24

The Organisation suggested that the DevOps Account’s security risk profile had

not been assessed, probably due to its intended use as an automation account. This
was not accepted. The Organisation is not exempted from assessing the security
implications and risks of the DevOps Account simply on the basis that it was an
automation account, especially considering that the DevOps Account could be used
to access the Customer Data stored in the Databases.

In view of the above, the Organisation was found to be in breach of the

Protection Obligation for its failure to review and assess the DevOps Account’s
security implications and risks.
Failure to implement reasonable ICT controls for DevOps Account
26

As stated in the Commission’s Guide to Data Protection by Design for ICT

Systems (2021), organisations should put in place ICT controls to manage data
protection risks (at page 9). Examples of ICT controls include setting appropriate
access control rules, access rights and restrictions for specific user roles, and
strengthening database security (at pages 15 and 18).
27

The Organisation informed the Commission that 2FA had not been

implemented for the DevOps Account, which had privileged access to the Cloud
Platform containing API keys/tokens to the Databases, and consequently, the
Customer Data stored in the Databases. This meant that the DevOps Account is an
account with privileged access. Many of the Organisation’s other systems and services
had implemented 2FA for accounts with privileged access, and these were not
breached in the Incident as the external actor could not carry out a password reset on
these systems and services. In the present case, the external actor had been able to
access the Cloud Platform and the API keys/tokens to the Databases stored therein,
after carrying out password reset on the DevOps Account.
28

The Organisation could have guarded against this risk by strengthening ICT

controls for the DevOps Account. The Organisation could have limited access to the
password change functions of its DevOps Account. The Organisation could have
introduced an additional restriction on the password change function, by requiring 2FA
whenever there is a request to change passwords for the DevOps Account. The
Organisation had implemented this additional restriction for many of its systems and
services, which were not breached in the Incident as the external actor could not carry
out a password reset where 2FA was required. The Organisation could likewise have
implemented a 2FA requirement for effecting password resets for the DevOps
Account. This was an existing policy and practice that the Organisation had for other

accounts with privileged access, and it ought to also have been extended to the
DevOps Account which also had privileged access.
29

Accordingly, the Organisation was found to be in breach of the Protection

Obligation for failing to implement reasonable ICT controls for the DevOps Account.
The Commissioner’s Directions
30

In determining whether to impose a financial penalty on the Organisation

pursuant to section 48J(1) of the PDPA, and the amount of any such financial penalty,
the matters set out at section 48J(1) and the factors listed at section 48J(6) of the
PDPA were taken into account, as well as the following mitigating factors:
Mitigating Factors
(a)

The Organisation took prompt remedial actions, including notifying the

affected individuals; and
(b)
31

The Organisation was cooperative during investigations.

The Commission also considered the Organisation’s voluntary acceptance of

liability for the Incident.
32

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

hereby requires the Organisation to pay a financial penalty of $67,000 within 30 days
from the date of the relevant notice accompanying this decision, 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.
33

No further directions are necessary on account of the remedial measures

already taken by the Organisation.

YEONG ZEE KIN
DEPUTY COMMISSIONER
FOR COMMISSIONER FOR PERSONAL DATA PROTECTION

",Financial Penalty,050d292466354174c1fddecc90ae2ad45a68f635
27,27,1,952,Both organisations were found not in breach of the PDPA in relation to complaints regarding alleged collection and disclosure of personal data without consent.,"[""Consent"", ""Not in Breach"", ""Real Estate"", ""No breach""]",2022-06-16,https://www.pdpc.gov.sg/-/media/Files/PDPC/PDF-Files/Commissions-Decisions/Decision---SLP-Scotia-Pte-Ltd-and-SLP-International-Property-Consultants-Pte-Ltd---09042022.pdf,Consent,No Breach of the Consent Obligation by SLP Scotia and SLP International Property Consultants,https://www.pdpc.gov.sg/all-commissions-decisions/2022/06/no-breach-of-the-consent-obligation-by-slp-scotia-and-slp-international-property-consultants,2022-06-16,"PERSONAL DATA PROTECTION COMMISSION
Case No. DP-2007-B6585, DP-2007-B6591, DP-2007-B6594, DP-2007-B6598
In the matter of an investigation under section 50(1) of the
Personal Data Protection Act 2012
And
SLP Scotia Pte. Ltd.
SLP International Property Consultants Pte. Ltd.

SUMMARY OF THE DECISION

1. Between 10 to 14 July 2020, the Personal Data Protection Commission (the
“Commission”) received four complaints against SLP International Property
Consultants Pte Ltd (“SLPIPC”) and its subsidiary SLP Scotia Pte Ltd (“SLPS”)
(collectively, the “Organisations”). The complainants were property agents
registered through SLPS (the “Complainants”).

2. As a merger was due to take place between the Organisations, on 7 July 2020,
SLPIPC initiated the registration of salespersons in SLPS as salespersons in
SLPIPC with the Council of Estate Agencies (“CEA”). CEA thereafter emailed the
Complainants asking them to either initiate a salesperson application to join
SLPIPC or disregard the email if they were not interested in registering with
SLPIPC (the “Incident”).

3. The Complainants alleged that:
a. they had not consented to be contacted for such purposes; and
b. SLPS had improperly disclosed their personal data (including NRIC number,
date of birth, and home address) to SLPIPC, and SLPIPC had in turn
improperly disclosed the data to CEA.

4. CEA is the entity which administers the registration of salespersons (such as the
Complainants) under the Estate Agents Act 2010 (“EAA”). Pursuant to section
29(1) of the EAA, a person may not act as a salesperson for any estate agent
unless he or she is registered; the said register is maintained by the CEA pursuant
to section 36 of the EAA. Further, under section 40(1) of the EAA, a salesperson
may not be registered to act as a salesperson for more than one estate agent at
any one time.

5. SLPIPC disclosed the personal data of the Complainants to CEA for the purposes
of the change in registration from SLPS to SLPIPC. In doing so, SLPIPC was
complying with its obligations under the EAA. The disclosure by SLPIPC to CEA
was therefore not in breach of any of the provisions of the Personal Data Protection
Act 2012 (“PDPA”), as under section 4(6) of the PDPA, obligations of a party under
other written law take precedence over obligations under the PDPA.

6. The Commission’s investigation focused on whether the Organisations had
breached the Consent Obligation under section 13 of the PDPA in relation to:
a. the disclosure of the Complainants’ personal data by SLPS to SLPIPC; and
b. the collection of the said data by SLPIPC from SLPS.

7. Investigations revealed that the Complainants had each, individually and
separately, signed an agreement with SLPS (“Associate’s Agreement”) in which
they had provided their consent for disclosure of their personal data in specific
circumstances. Notably:
a. Clause 24 of the Associate’s Agreement provided that the Complainants
consented to SLPS collecting, using and/or disclosing their personal data
for one or more of the “Company Purposes”.
b. “Company Purposes” as defined in the Associate’s Agreement included
disclosure of the Complainants’ personal data to SLPS’ related
corporations, to facilitate and administer the real estate brokerage services
to be provided by the Complainants under the Associate’s Agreement.
c. As SLPS was a subsidiary of SLPIPC, both Organisations were “related
corporations” for the purposes of the Associate’s Agreement.

8. The disclosure and collection of the Complainants’ personal data had been carried
out because of an upcoming merger between the Organisations, for business
reasons. With the move towards merger at the material time, the Complainants had

the option of providing their services under SLPIPC after the merger. This was
found to fall under the ambit of “Company Purposes” pursuant to Clause 24 of the
Associate’s Agreement, because the merger would have affected the
Complainants’ ability to “facilitate and administer” their real estate brokerage
services.

9. Consequently, the disclosure of the Complainants’ personal data by SLPS and the
collection and disclosure of the same by SLPIPC as a related corporation was
found to be consistent with the purposes for which the Complainants had provided
consent in the Associate’s Agreement.

10. In light of the above, the Deputy Commissioner for Personal Data Protection finds
that the Organisations did not breach the Consent Obligation under section 13 of
the PDPA.

The following is the provision of the Personal Data Protection Act 2012 cited in the
above summary:
Consent required
13. An organisation must not, on or after 2 July 2014, collect, use or disclose personal data about an
individual unless —
(a)
the individual gives, or is deemed to have given, his or her consent under this Act to the
collection, use or disclosure, as the case may be; or
(b)
the collection, use or disclosure (as the case may be) without the individual’s consent is
required or authorised under this Act or any other written law.

",Not in Breach,81943b55f3e50d31e820edf46499ec3602f370c0
28,28,1,952,Aman was found not in breach of the PDPA in relation to an incident involving unauthorised access to its servers and exfiltration of personal data. Aman had employed reasonable security arrangement and technical measures to protect its data.,"[""Protection"", ""Not in Breach"", ""Accommodation and F&B""]",2022-06-16,https://www.pdpc.gov.sg/-/media/Files/PDPC/PDF-Files/Commissions-Decisions/Decision--Aman-Group-Sarl-and-or-Amanresort-International-Pte-Ltd--28022022.pdf,Protection,No Breach of the Protection Obligation by Aman Group S.a.r.l and Amanresort International,https://www.pdpc.gov.sg/all-commissions-decisions/2022/06/no-breach-of-the-protection-obligation-by-aman-group,2022-06-16,"PERSONAL DATA PROTECTION COMMISSION

Case No. DP-2012-B7506

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

And

Aman Group S.a.r.l and/or
Amanresort International Pte Ltd

SUMMARY OF THE DECISION

1. On 5 December 2020, the Personal Data Protection Commission (the
“Commission”) received a notification from SingCERT of a personal data
breach involving Aman Group S.a.r.l (“Aman Group”) and/or Amanresort
International Pte Ltd (“Aman SG”). 9 systems in London and 2 systems in
Singapore were compromised and files containing personal data exfiltrated (the
“Incident”).

Page 1 of 4

2. As a result of the Incident, personal data of approximately 2,500 individuals
which included their name, date of birth, address, email address, phone number
and profession were affected.

3. The Aman Group engaged an external cybersecurity company, Ankura
Consulting, to investigate the Incident. Its investigations found that the threat
actor(s) had gained unauthorised access into 11 systems, which included 9
servers based in London and 2 servers based in Singapore.

4. While the investigations did not uncover any evidence of what the initial method
and point of entry were, the most likely scenario is that the threat actor had
initially entered via the London based systems. This is because the suspicious
activities were first detected in the London systems. Thereafter, the threat actor
subsequently gained access to the 2 Singapore based servers by creating
administrator account credentials. There was no evidence that the firewalls in
the Singapore based servers were breached.

5. Investigations could not conclusively exclude the possibility that data may have
been exfiltrated from one of the Singapore based servers. However, analysis
conducted by the Aman Group on four extracts obtained from the threat actor(s)
failed to establish any conclusive links between the extracts and the current
database in the affected Singapore based server.

6. Investigations further revealed that any exfiltrated data would have been
encrypted and was in a proprietary format. Aman Group’s assessment was that

Page 2 of 4

the encryption and the proprietary format made it unlikely that the threat actor(s)
would be able access and recreate the data in plaintext. Their assessment is
that even if there had been exfiltration, there was no evidence that the
exfiltrated data was in fact compromised. This is because the extracts obtained
from the threat actor(s) do not resemble the current database in the affected
Singapore based server.

7. Following the Incident, the Aman Group took prompt and extensive remedial
actions to mitigate the effects of the Incident and enhance the robustness of its
security measures.

8. Further, based on the facts as disclosed, Aman SG is a regional office. It did
not hold the data protection role and was not in possession or control of the
personal data in the 2 Singapore based servers. As such, Aman SG could not
be held accountable for the Incident and cannot be said to be in breach of the
Protection obligation under section 24 of the PDPA.

9. In view of the above, the Deputy Commissioner for Personal Data Protection is
satisfied of the view that the Aman Group had met its Protection obligation
under section 24 of the Personal Data Protection Act (“PDPA”) and that no
enforcement action needs to be taken in relation to the Incident.

Page 3 of 4

The following provision(s) of the Personal Data Protection Act 2012 had been cited in the
above summary:
Protection of personal data
24. An organisation shall protect personal data in its possession or under its control by
making reasonable security arrangements to prevent –
(a) unauthorised access, collection, use, disclosure, copying, modification, disposal or
similar risks; and
(b) the loss of any storage medium or device on which personal data is stored.

Page 4 of 4

",Not in Breach,5e015c5637baabcfc9d1ffcaae0eb7490cbabe57
29,29,1,952,"Ngian Wen Hao Dennis, Chua Puay Hwa Melissa and Winarto were found in breach of the PDPA and issued warnings in relation to two incidents involving the unauthorised collection and disclosure of individuals’ personal data in 2019 and 2020.","[""Consent"", ""Notification"", ""Warning"", ""Finance and Insurance""]",2022-06-16,https://www.pdpc.gov.sg/-/media/Files/PDPC/PDF-Files/Commissions-Decisions/Decision---Dennis-Ngian--Others---08032022.pdf,"Consent, Notification",Breach of the Consent and Notification Obligations by three insurance financial advisers,https://www.pdpc.gov.sg/all-commissions-decisions/2022/06/breach-of-the-consent-and-notification-obligations-by-three-insurance-financial-advisers,2022-06-16,"PERSONAL DATA PROTECTION COMMISSION
Case No. DP-2109-B8857

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

And

(1) Ngian Wen Hao Dennis
(2) Chan Puay Hwa Melissa
(3) Winarto
(4) Aviva Financial Advisers Pte Ltd

SUMMARY OF THE DECISION

1. On 7 September 2021, the Personal Data Protection Commission (the
“Commission”) was notified of two incidents involving unauthorised disclosure and
collection of personal data by three individuals.

2. Ngian Wen Hao Dennis (“Dennis”) was an Aviva Financial Advisers Pte Ltd
(“AFA”) representative between December 2017 and February 2019. In March
2019 and August 2020, Dennis approached two insurance financial advisers, Chua
Puay Hwa Melissa (“Melissa”) and Winarto, to offer them a list of client leads,
stating that he was leaving the insurance industry and looking for a reliable agent
1

to take over his clientele. Melissa and Winarto each said they paid $1,000 to Dennis
for the list (the “Incidents”).

3. The list contained approximately 1,000 clients’ names, mailing addresses, contact
numbers and the names of organisations underwriting the hospitalisation plans
bought by the clients (“Personal Data Sets”).

4. The PDPA defines “organisations” to include individuals. As held in Re Sharon
Assya Qadriyah Tang1, individuals who collect, use or disclose personal data
otherwise than in a personal or domestic capacity will be treated as organisations
within the meaning of the Act, and are obliged to comply with the Data Protection
Provisions. In this case, we are of the view that it is clear that Dennis, Melissa and
Winarto can be regarded as an “organisation” as defined under the PDPA for a
number of reasons. First, the trio had bought and sold the client leads for work and
business purposes, with the aim of generating an income or profit, and cannot be
said to have been acting in a personal or domestic capacity.
5. Second, Dennis, Melissa and Winarto were not employees. In Re Ang Rui Song2,
the Commission found that the respondent, a financial consultant with Prudential
Assurance Company (Pte) Ltd, had been engaged on such terms that he was in
effect an independent contractor rather than an employee of Prudential. The same
applies to the trio. The Representative Agreement between AFA and Dennis

1
2

[2018]SGPDPC 1.
[2017] SGPDPC 13.

expressly provides that “nothing in [the] Agreement shall constitute, or be
construed, or deemed to constitute, any employment…between [Dennis] and
[AFA]”.

Dennis

6. Having found that the PDPA applies, we now turn to consider the data protection
obligations applicable to the different parties concerned. Dennis conceded that he
approached Melissa and Winarto to transfer his list of client leads to them. Our
investigations revealed that Dennis’ claim that he had obtained the necessary
consent and duly notified the clients on the list regarding the disclosure of their
personal data to other insurance financial advisers could not be corroborated.
None of the clients verified Dennis’ claim that he had contacted them to seek their
consent or notified them of the disclosure of their personal data to other insurance
financial advisers. We are therefore of the view that Dennis has breached the
Consent and Notification Obligation under the PDPA in that he did not obtain his
clients’ consent before disclosure of their personal data.

Melissa and Winarto
7. Both Melissa and Winarto admitted to the collection (purchase) of the client list
from Dennis. They claimed to have relied on the verbal assurances provided by
Dennis that he had informed the clients about the change in their insurance
financial adviser. In Re Amicus Solutions Pte Ltd and Ivan Chua Lye Kiat [2019]
3

SGPDPC 33 (at [49]), we stated that a reasonable person should undertake proper
due diligence, such as obtaining from the seller a sample of the written notifications
and consent. In our view, Melissa and Winarto have failed to take reasonable steps
to verify from Dennis that there had been proper notification to and consent
obtained from the clients for the disclosure of their personal data. In collecting (i.e.
buying) the client list, we find that Melissa and Winarto are in breach of the
Notification and Consent Obligations under the PDPA.

AFA

8. The Commission found no evidence of breach of the PDPA by AFA in the Incidents.
As stated in [5], Dennis was not an employee of AFA for whose acts AFA may be
liable through section 53(1) of the PDPA. Dennis claimed that the Personal Data
Sets were not retrieved from AFA’s systems and that he had compiled the list on
his own accord to keep track of his clientele during his time as an independent
financial adviser with AFA. This was consistent with AFA’s own investigations. Our
investigations also revealed that AFA had reasonable policies and security
measures in place for personal data protection. These included data leak
prevention controls and monitoring of AFA corporate network to prevent
representatives from exporting clients’ data from its systems. Contractual terms
were also in place to require representatives to comply with the PDPA. AFA issued
a letter to Dennis, upon the termination of the relationship between them, referring
to the need to return “all policies, rate books, receipts, manuals, literature, lists and
personal information of Customers”.
4

The Commission’s Decision
9. The sale of personal data by organisations without obtaining the consent of the
individuals involved is a serious breach of the PDPA. In Re Sharon Assya Qadriyah
Tang at [30], we had stated as follows:
There are strong policy reasons for taking a hard stance
against the unauthorised sale of personal data. Amongst these
policy reasons are the need to protect the interests of the
individual and safeguard against any harm to the individual,
such as identity theft or nuisance calls. Additionally, there is a
need to prevent abuse by organisations in profiting from the
sale of the individual’s personal data at the individual’s
expense. It is indeed such cases of potential misuse or abuse by
organisations of the individual’s personal data which the PDPA
seeks to safeguard against. In this regard, the Commissioner is
prepared to take such stern action against organisations for the
unauthorised sale of personal data.
[Emphasis added.]

10. To curb this form of abuse of personal data, the amount of profit made by the
organisation from the sale may be factored in determining the financial penalty that
the organisation may be required to pay. Indeed, had the sale taken place after the
2020 amendments to the PDPA, this would have been a specific consideration
under section 48J(6)(c): “whether the organisation or person (as the case may be),
as a result of the non‑compliance, gained any financial benefit”.

11. In determining the enforcement action in response to the breach by Dennis, the
Commission took into account the cooperation extended to the investigation, and
5

the full refund made by Dennis of the proceeds he made from the sale. The
Commission also considered that Dennis is in poor health, has been unemployed
since 2018, has little savings in his bank account, and is dependent on his aged
father for financial support. Having considered the state of Dennis’ health and
financial status, the Commission is of the view that a financial penalty would
impose a crushing burden on him and his family, resulting in undue hardship.
Accordingly, taking into account all relevant factors, the Commission has decided
to administer a warning in respect of the breach by Dennis of the Consent and
Notification Obligations. The Commission wishes to emphasize that this
assessment that undue hardship may occur following the imposition of a financial
penalty is not a finding that the Commission will make easily and will be reserved
only for the most deserving and exceptional cases. Individuals who seek to misuse
personal data for profit and are found to be in breach of the PDPA must expect to
pay a heavy financial penalty.

12. Turning to Melissa and Winarto, the Commission has decided to administer
warnings to Melissa and Winarto in respect of their breaches of the Consent and
Notification Obligations. In so deciding, the Commission considered that both of
them did not sell the personal data for profit and had been cooperative throughout
the investigations. More importantly, neither of them used the personal data they
obtained without consent from the individuals involved.

The following provisions of the Personal Data Protection Act 2012 (pre-amendment in
2020) had been cited in the above summary:
Consent and Notification Obligations (Section 13 read with 20 of the PDPA)
Pursuant to section 13 of the PDPA, unless an exception to consent is applicable,
organisations are generally required to obtain the consent of an individual before
collecting, using and/or disclosing the individual’s personal data (“Consent
Obligation”).
Consent must be obtained from the individual with reference to the intended purpose
of the collection, use or disclosure of the personal data. The organisation’s collection,
use and disclosure of personal data are limited to the purposes for which notification
has been made to the individuals concerned. In this regard, organisations have an
obligation under section 20 of the PDPA to inform individuals of the purposes for which
their personal data will be collected, used and/or disclosed, on or before collecting the
personal data in order to obtain consent (“Notification Obligation”).

Protection Obligation (Section 24 of the PDPA)
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.

",Warning,11afc51e552a655c8c243aa724648b2011a2eb25
30,30,1,952,"A financial penalty of $22,000 was imposed on Vhive for failing to put in place reasonable security arrangements to protect the personal data in its possession from a ransomware attack.","[""Protection"", ""Financial Penalty"", ""Wholesale and Retail Trade"", ""Ransomware""]",2022-06-16,https://www.pdpc.gov.sg/-/media/Files/PDPC/PDF-Files/Commissions-Decisions/Decision---Vhive-Pte-Ltd---08032022.pdf,Protection,Breach of the Protection Obligation by Vhive,https://www.pdpc.gov.sg/all-commissions-decisions/2022/06/breach-of-the-protection-obligation-by-vhive,2022-06-16,"PERSONAL DATA PROTECTION COMMISSION
Case No. DP-2013-B8138
In the matter of an investigation under section 50(1) of the
Personal Data Protection Act 2012
And
Vhive Pte Ltd

SUMMARY OF THE DECISION

On 26 March 2021, Vhive Pte Ltd (the “Organisation”) notified the Personal Data
Protection Commission (the “Commission”) of a ransomware attack that
affected its customer database (the “Incident”). Approximately 186,281
individuals’ names, addresses, email addresses, telephone numbers, hashed
passwords and customer IDs were affected.

The Organisation subsequently requested for this matter to be handled under the
Commission’s expedited breach decision procedure. This means that the
Organisation voluntarily provided and unequivocally admitted to the facts set out
in this decision, and admitted that it was in breach of section 24(a) of the Personal
Data Protection Act (the “PDPA”).

The Organisation’s forensic investigation results revealed that the Organisation’s
IT infrastructure had been outdated, with multiple vulnerabilities at the time of the
Incident. The Organisation’s e-commerce server ran on an outdated webserver
service. This, together with an unpatched firewall, allowed the threat actor to

remotely execute unauthorised code on the e-commerce server, and gained
backdoor access to the e-commerce server to carry out the ransomware attack.

The Organisation had engaged an IT vendor to host, manage and maintain the
e-commerce server and all its other IT systems. However, our investigations
revealed that despite the purported “engagement”, there was in fact no written
contract between the Organisation and its IT vendor at the time of the Incident.

In Re Spize Concepts Pte Ltd [2019] SGPDPC 22 at [22], we had stated that
section 4(2) of the PDPA imposes on organisations that engage data
intermediaries to do so “pursuant to a contract which is evidenced or made in
writing”. In that case, we also highlighted that one specific category of policies
and practices under section 12(a) of the PDPA that an organisation should
develop and implement is the contractual documentation relating to the scope of
the data intermediary relationship, and failure to do so would amount to a breach.
The raison d’etre is that the outsourcing of data processing activities must be
clearly scoped, and the respective roles and responsibilities between the
organization and the data intermediary clearly identified from the outset. In the
absence of any written contract and the lack of evidence to show the scope, roles
and responsibilities of the data processing outsourcing, the Organisation
remained solely responsible for complying with the obligations under the PDPA,
including the obligation to make reasonable security arrangements to protect the
personal data in its possession or under its control under section 24 of the PDPA.

The Organisation’s outdated webserver was used to host the Organisation’s
website and its online storefront. In this regard, the Commission had previously
2

issued a Guide on Building Websites for SMEs in 2016, which was subsequently
updated and revised in July 2018. In this Guide, the Commission emphasized
the importance of ensuring the protection of personal data and the security of the
website throughout the life cycle, including ensuring the clear delineation of
responsibilities when an organization engages an IT vendor.

We wish to reiterate our observations in [4.2.1] of the Guide, where we
highlighted the need to consider and properly document an IT vendor’s scope of
work, and stated as follows:
Organisations should emphasise the need for personal data protection to their
IT vendors, by making it part of their contractual terms. The contract should also
state clearly the responsibilities of the IT vendor with respect to the PDPA.
When discussing the scope of outsourced work, organisations should consider
whether the IT vendor’s scope of work will include any of the following:
•

Requiring that IT vendors consider how the personal data should be handled
as part of the design and layout of the website.

•

Planning and developing the website in a way that ensures that it does not
contain any web application vulnerabilities that could expose the personal
data of individuals collected, stored or accessed via the website through the
Internet.

•

Requiring that IT vendors who provide hosting for the website should ensure
that the servers and networks are securely configured and adequately
protected against unauthorised access.

•

Requiring IT vendors to ensure that all work done is fully documented and
that all documentation is handed over to the organisation at the completion
of the project. Documents should capture the website’s requirements,
design specifications, user test scripts, user test results, as well as server
and network configurations.

•

When engaging IT vendors to provide maintenance and/or administrative
support for the website, requiring that any changes they make to the website
do not contain vulnerabilities that could expose the personal data.
Additionally, discussing whether they have technical and/or non-technical
processes in place to prevent the personal data from being exposed
accidentally or otherwise.

•

Requiring that IT vendors providing maintenance and/or administrative
support to ensure that all changes to the website are secure and
documented, and that the document is kept up to date.

The Organisation admitted the weakness in its IT infrastructure and its failure to
give due attention to the protection of the personal data of its customers had
contributed to the Incident.

On the facts, the Organisation’s failure to ensure that there was a written contract
with its IT vendor not only meant that there was a lack of clarity on the scope of
work expected from the IT vendor, but also that the Organisation had failed to
stipulate clear written security maintenance requirements and data protection
requirements to its IT vendor to ensure the protection of personal data it was in
control or in possession of. This ultimately resulted in a lack of system
maintenance, including security maintenance by the Organisation.

10. Investigations further revealed that the Organisation did not have a security
maintenance policy, which would have made up for the lack of specification of
these requirements to its IT vendor, nor did the Organisation conduct any of its
own scheduled security reviews, through which it could have detected any
security inadequacy or vulnerabilities within its IT infrastructure.

11. In the above circumstances, the Organisation is found to have breached the
Protection Obligation under section 24(a) of the PDPA.

12. Following the Incident, the Organisation decommissioned its e-commerce
webserver and overhauled its IT infrastructure. Apart from deciding to conduct
online sales solely through third party websites, the Organisation also rebuilt its
ERP server in a secure environment with new set of firewalls, updated its
4

operating systems and software, implemented the use of SSL-VPN for remote
access, and engaged a new IT vendor with the data security and data protection
provisions properly specified in a written contract. The Organisation also
reviewed and updated all its internal policies relevant to the protection of personal
data.

13. In deciding the appropriate outcome in this case, the Commission acknowledges
the cooperation extended by the Organisation to the Commission throughout the
course of our investigations. The Organisation had also voluntarily admitted to
its breach of the Protection Obligation, and took prompt remediation actions to
address its security gaps. The Organisation was able to restore fully the personal
data affected without loss, thereby minimizing any disruptions to its operations.

14. Having considered the circumstances set out above and the factors listed at
section 48J(6) of the PDPA, the Commissioner for Personal Data Protection
hereby finds the Organisation in breach and requires the Organisation to pay a
financial penalty of $22,000 within 30 days from the notice accompanying date
this decision, 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.

15. In view of the remedial action by the Organisation, no directions under section
48I are necessary.

(a) unauthorised access, collection, use, disclosure, copying, modification, disposal or similar risks;
and
(b) the loss of any storage medium or device on which personal data is stored.

",Financial Penalty,5c70e87aac9ad5ab303f0f8cb9f8f4094c224e02
31,31,1,952,"Warnings were issued to Toll Logistics (Asia), Toll Global Forwarding, Toll Offshore Petroleum Services, and Toll (TZ) for breaches of the PDPA in relation to the transfer of employees’ personal data to a human resources software vendor in Ireland.","[""Transfer Limitation"", ""Warning"", ""Transport and Storage""]",2022-05-19,https://www.pdpc.gov.sg/-/media/Files/PDPC/PDF-Files/Commissions-Decisions/Decision--Toll-Logistics-Asia-Limited-and-others--180322.pdf,Transfer Limitation,Breach of the Transfer Limitation Obligation by Toll Logistics (Asia) and others,https://www.pdpc.gov.sg/all-commissions-decisions/2022/05/breach-of-the-transfer-limitation-obligation-by-toll-logistics-and-others,2022-05-19,"PERSONAL DATA PROTECTION COMMISSION

[2022] SGPDPC 4

Case No. DP-2008-B6707

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

And

(1) Toll Logistics (Asia) Limited
(2) Toll Global Forwarding (Singapore) Pte. Limited
(3) Toll Offshore Petroleum Services Pte. Ltd.
(4) Toll (TZ) Pte. Ltd.
… Organisations

DECISION

Toll Logistics (Asia) Limited and others

[2022] SGPDPC 4
Yeong Zee Kin, Deputy Commissioner — Case No. DP-2008-B6707
14 March 2022

Introduction
1

Toll Holdings Limited (“Toll Holdings”) is an integrated logistics services

provider headquartered in Australia. Toll Logistics (Asia) Limited (“Toll Logistics”),
Toll Global Forwarding Singapore Pte. Ltd. (“Toll Forwarding”), Toll Offshore
Petroleum Services Pte. Ltd. (“Toll Offshore""), and Toll (TZ) Pte. Ltd. (“Toll TZ”) are
Singapore-registered entities (collectively, “the Organisations”) that are part of a
multinational group of companies headed by Toll Holdings (“the Group”).
2

On 11 June 2020, Toll Holdings notified the Personal Data Protection

Commission (“the Commission”) of a ransomware attack which had affected the
Group’s IT systems, including servers in Australia and Singapore containing the
personal data of current and former employees of the Organisations (“the Incident”).
The Commission subsequently received complaints from 3 former employees of Toll
Logistics in relation to the Incident. Investigations were commenced to determine
whether the circumstances relating to the Incident disclosed any breaches by the
Organisations of the Personal Data Protection Act 2012 (“PDPA”).
Facts of the Case
3

In July 2013, Toll Holdings contracted with a vendor in Ireland (“the HR

Vendor”) for the Group’s use of the HR Vendor’s human resources software platform
(“the HR Platform”). To facilitate use of the common HR Platform, the respective
Group entities (including the Organisations) uploaded the personal data of their
employees to the HR Platform. The data uploaded to the HR Platform was hosted by
the HR Vendor in data centres in the European Economic Area.

Subsequently in 2019, a series of Corporate Services Agreements (“CSAs”)

and accession agreements were executed with the net effect that Toll Holdings
undertook to provide finance, human resources (“HR”), information technology (“IT”),
legal, and other corporate services to all the Organisations. Although the CSAs were
inked in 2019, they took retrospective effect from 1 April 2018.
5

The services provided by Toll Holdings to the Organisations under the CSAs

included:

(a)

Development and maintenance of HR policies and procedures;

(b)

Development and maintenance of IT strategy;

(c)

Development and maintenance of IT policies and procedures; and

(d)

Provision of IT support services.

Under the terms of the CSAs, Toll Holdings was permitted to appoint

subcontractors to perform part or all of the services subject of the CSAs but was
responsible to the same extent as if it had performed the services itself.
7

The scope of IT services to be provided by Toll Holdings under the CSAs

specifically excluded the “development or implementation of IT systems”, which
responsibility presumably remained with the Organisations. To this end, the
Organisations maintained ten servers in Singapore to support their operations. Three
of these servers (“the Singapore Servers”) were used by the Organisations’
corporate teams (i.e. finance, legal, HR) in the ordinary course of their work and
contained personal data within the email archives and other working documents.
8

The Group (including the Organisations) had implemented various industry-

standard security solutions for its IT systems such as end-point protection software,
logging and monitoring software and/ services, firewall and intrusion prevention
software, security detection and response software, identity access management and
control software and services, vulnerability scanning software and services, and
patching software. A Managed Security Service Provider (“MSSP”) was also engaged
to provide cyber security detection and incident response services for the Group. With
3

the assistance of the MSSP and other external vendors, the Group carried out regular
vulnerability scanning and penetration testing of its IT systems.
Transfer of personal data to Australia
9

Sometime prior to the Incident, Toll Holdings’ Chief Human Resources Officer

extracted personal data relating to 1,748 of the Organisations’ current and former
employees from the HR Platform and transmitted them to a server in Australia (“the
Australia Server”). Toll Holdings represented that this personal data was transferred
for the purposes of performing services for the Organisations pursuant to the CSAs.
10

The personal data downloaded by Toll Holdings comprised each employee’s:
(a)

Name;

(b)

Address

(c)

Age; and

(d)

Salary.

5 employees of Toll Logistics and 2 employees of Toll Forwarding also had

other datasets disclosed including:
(a)

Driver’s licence number;

(b)

Emergency contact details;

(c)

National ID;

(d)

Fingerprint;

(e)

Medical details; and

(f)

Passport details.

The Incident
12

On 26 April 2020, a malicious actor gained access to Toll Holdings’ IT

environment in Australia using credentials stolen from a third-party vendor. The thirdparty vendor had been granted administrative access to two servers in Toll Holding’s
IT environment in order to provide support services for a software solution.
13

Having gained access to the Group’s IT environment, the malicious actor used

advanced malware and a range of hacking tools to move through the Group’s network,
conduct reconnaissance, and escalate account privileges. The malicious actor also
made various efforts to bundle and compress data from the Australia Server and stage
it for exfiltration.
14

Threat monitoring software deployed by the Group detected events related to

the malicious actor’s account takeover and privilege escalation during the Incident and
raised alerts to the MSSP. However, according to Toll Holdings, no alerts were brought
to its attention. On 3 May 2020, the malicious actor exfiltrated less than 2% (two
percent) of the data stored on the Australia Server using a web-based file sharing
service. The malicious actor then ran scripts to disable various endpoint protections
across the Group and executed a ransomware attack. The ransomware attack
encrypted files on a number of the Group’s servers, including the Australia Server and
the Singapore Servers.
15

When subsequently making ransom demands, the malicious actor provided Toll

Holdings a summary of the files exfiltrated from the Australia Server and eventually
uploaded portions of the exfiltrated files onto the dark web. Based on (i) the summary
provided by the malicious actor, (ii) the Group’s review of the available logs and
records on the Australia Server, and (iii) a review of the files eventually published by
the malicious actor on the dark web, the Organisations concluded that there was no
evidence of exfiltration of the personal data of its current or former employees from
the Australia Server.
16

The Organisations also concluded that there was no evidence of data

exfiltration from the Singapore Servers, or any other servers in the Group’s IT
environment in the Incident, other than the Australia Server. The Organisations were
5

able to restore the encrypted data in the Singapore Servers from securely stored backups.
Remedial actions
17

Following the Incident, Toll Holdings implemented the following remedial

measures on a Group-wide basis:
(a)

Temporarily disconnected from the Internet, and undertook a rolling

shutdown of IT systems in order to mitigate spread of any infection;
(b)

Isolated all impacted servers and implemented network restrictions to

prevent spread of the ransomware within the Group’s network;
(c)

Engaged third-party experts to assist with incident response, including

investigation and remediation;
(d)

Upgraded its user access system and reset all administrator passwords;

(e)

Blocked the malware used in the Incident;

(f)

Removed access privileges obtained by the malicious actor;

(g)

Implemented additional vulnerability scanning across the Group’s IT

systems to harden the Group’s network perimeter;
(h)

Strengthened the Group’s Active Directory infrastructure;

(i)

Implemented additional end point protection, forensic tools, and

monitoring tools;
(j)

Introduced a shadow security operations centre and initiated transition

to a new MSSP;
(k)

Initiated plans for an asset lifecycle review to identify legacy critical

business applications and treatment required to address cyber risks;
(l)

Commenced a logging, monitoring and alerting uplift to review existing

policies and standards;
6

(m)

Completed the rollout of multi-factor authentication for all remote access;

(n)

Updated organisational measures such as incident response plans,

policies, and playbooks; and
(o)

Rolled out a cyber awareness programme containing training and

assignments for its employees
Findings and Basis for Determination
18

Based on the circumstances of the Incident, the Commission’s investigation

centred on:
(a)

Whether the Organisations had breached their respective obligations

under section 26 of the PDPA to not transfer any personal data to a country or
territory outside Singapore except in accordance with requirements prescribed
under the PDPA (the “Transfer Limitation Obligation”); and
(b)

Whether the Organisations had breached their respective obligations

under section 24 of the PDPA to protect personal data in their possession or
under their control by making reasonable security arrangements to prevent
unauthorised access, collection, use, disclosure, copying, modification,
disposal or similar risks (the “Protection Obligation”).
Whether the Organisations had contravened the Transfer Limitation Obligation
19

The HR Platform was implemented on a Group-wide basis on or around July

2013. The Organisations began uploading the personal data of their employees to the
HR Platform for storage in the HR Vendor’s servers in the European Economic Area
around this time, and would have continued to do so as part of the normal course of
HR functions (for example, when new employees joined). Any transfers of personal
data by the Organisations out of Singapore after 2 July 2014 would have been subject
to the Transfer Limitation Obligation and the requirements prescribed in Part III of the
Personal Data Protection Regulations 2014 (“PDPR 2014”). For transfers of personal
data outside of Singapore which occurred after 1 February 2021, such transfers would

have been subject to the requirements in Part 3 of the Personal Data Protection
Regulations 2021 (“PDPR 2021”).
20

Regulation 9(1)(b) of the PDPR 2014 and regulation 10(1) of the PDPR 2021

require an organisation that transfers personal data outside of Singapore to take
appropriate steps to ensure that the recipient of the personal data is bound by legally
enforceable obligations to provide the transferred personal data a standard of
protection that is at least comparable to that under the PDPA. Under regulation 10 of
the PDPR 2014 and regulation 11(1) of the PDPR 2021, such legally enforceable
obligations can be imposed on the recipient organisation under (a) any law; (b) any
contract between the parties; (c) binding corporate rules; or (d) any other legally
binding instrument.
21

In gist, the Organisations were required to take appropriate steps to ensure

that the personal data transferred out of Singapore via the HR Platform for storage in
the European Economic Area would be protected to a standard comparable to under
the PDPA, before any such transfers were made.
22

There was no evidence of any such steps taken by the Organisations. While

the contract between Toll Holdings and the HR Vendor included data protection
obligations imposed on the HR Vendor, the Organisations were not party to this
agreement. The CSAs also did not contain any provisions relating to the protection of
personal data or impose obligations on Toll Holdings to protect the personal data of
the other Organisations for the purposes of the centralised corporate functions to be
undertaken pursuant to the CSAs. Accordingly, the Organisations were determined to
have contravened the Transfer Limitation Obligation in relation to the personal data
uploaded on to the HR Platform.
23

In the course of investigations, Toll Holdings represented that it had since

reviewed the data transfer arrangements under the CSAs and that the Organisations
and Toll Holdings have now executed a “Singapore Data Export Agreement” to govern
intra-group transfers of personal data from the Organisations to Toll Holdings (and
other members of the Group who may subsequently become party to the agreement)

to ensure that a standard of protection comparable to the PDPA is provided to any
transferred personal data.
Whether the Organisations had contravened the Protection Obligation
24

As held in Everlast Projects Pte Ltd and others [2020] SGPDPC 20, members

of a corporate group may satisfy the Protection Obligation by relying on binding grouplevel written policies or intra-group contracts which specify the respective data
protection obligations of the members of the group. In the present case, while the
Organisations had entered into the CSAs to centralise various corporate functions with
Toll Holdings, the CSAs did not deal with data protection obligations. In the
circumstances, the Protection Obligation remained with the Organisations, and the
Organisations cannot rely on the CSAs to say that certain of its data protection
operations had been centralised with Toll Holdings at the Group-level.
25

That being said, under the CSAs, Toll Holdings had undertaken to provide the

Organisations with IT support services. It has been held in WTS Automotive Services
Pte Ltd [2018] SGPDPC 26 that organisations can rely on the technical expertise of
their service providers to satisfy the Protection Obligation (subject to clear instructions
or business requirements being specified). In the case where a member of a group of
companies provides technical support services to others in the group, it is advisable
that their respective roles and responsibilities be clearly spelt out.
26

In the present case, the CSAs were intended to perform this role: Toll Holdings

was responsible for IT support services while the Organisations remained responsible
for development and implementation of IT systems: see [7] above. As part of the IT
support services provided, Toll Holdings introduced and implemented Group-level IT
security standards. These were communicated through the Group’s intranet and
implemented by Toll Holdings on a Group-wide basis, as part of the IT support services
they provided. In accordance with these standards, a number of industry-standard
technical solutions and tools were implemented prior to the Incident to protect the
personal data in the Singapore Servers: see [8] above.
27

Having considered these security arrangements, we are satisfied that the

Organisations had not breached their Protection Obligation as the security
9

arrangements in place prior to and at the time of the Incident to protect the personal
data in the Singapore Servers were reasonable and consistent with existing industry
standards. In coming to this decision, we are also of the view that the security lapse
and privilege escalation that enabled the malicious actor to overcome the
Organisations’ endpoint protections in the Incident occurred abroad arising from theft
of credentials from Toll Holdings’ vendor and was beyond the control of the
Organisations.
The Deputy Commissioner’s Decision
28

In determining what directions (if any) should be given to the Organisations

pursuant to section 48I of the PDPA, the Deputy Commissioner took into
consideration:
(a)

the Organisations’ cooperation with the Commission’s investigations;

(b)

that access to the transferred personal data was limited to entities within

the same corporate group;
(c)

that there was no evidence of any loss or damage resulting from the

Organisations’ contravention of the Transfer Limitation Obligation; and
(d)

that the Group had already implemented intra-group contractual

arrangements to govern future transfers of personal data by the Organisations
to Toll Holdings.
29

Having considered all the mitigating factors listed above, the Organisations are

administered a warning in respect of their breach of the Transfer Limitation Obligation.
No other directions are necessary in view of the remedial actions already taken by the
Organisations.

YEONG ZEE KIN
DEPUTY COMMISSIONER
FOR PERSONAL DATA PROTECTION

",Warning,3366d27f6930503cebbbff6dd8de747f0da55d18
32,32,1,952,"A financial penalty of $2,000 was imposed on Southaven Boutique for failing to put in place reasonable security arrangement to prevent the unauthorised access of its customers' personal data in its Point-Of-Sale system server. An application for reconsideration was filed against the Decision Re Southaven Boutique Pte Ltd. Upon review and careful consideration of the application, direction in the Decision was varied and the financial penalty imposed was reduced.","[""Protection"", ""Financial Penalty"", ""Wholesale and Retail Trade"", ""Ransomware""]",2022-05-19,https://www.pdpc.gov.sg/-/media/Files/PDPC/PDF-Files/Commissions-Decisions/Decision---Southaven-Boutique-Pte-Ltd---280222.pdf,Protection,Breach of Protection Obligation by Southaven Boutique,https://www.pdpc.gov.sg/all-commissions-decisions/2022/05/breach-of-protection-obligation-by-southaven-boutique,2022-05-19,"PERSONAL DATA PROTECTION COMMISSION
Case No. DP-2102-B7854
In the matter of an investigation under section 50(1) of the
Personal Data Protection Act 2012
And
Southaven Boutique Pte Ltd

Editorial note: An application for reconsideration was filed against the decision
in Re Southaven Boutique Ptd Ltd. Pursuant to this application, the Deputy
Commissioner has decided to reduce the financial penalty imposed on the
Organisation from $5,000 to $2,000. As the application did not give rise to
significant legal or factual issues, a separate decision on the application will not
be published.
SUMMARY OF THE DECISION

1. On 5 February 2021, Southaven Boutique Pte Ltd (the “Organisation”), a brickand-mortar retailer of clothes and accessories, informed the Personal Data
Protection Commission (the “Commission”) of a ransomware attack that occurred
on or about 4 February 2021 (the “Incident”). A threat actor had gained access to
the Organisation’s Point-Of-Sale (the “POS”) system server and encrypted the
personal data of 4,709 customers. The personal data affected include names,
addresses, email addresses, contact numbers and date of birth.

2. Investigations revealed that the Organisation did not implement adequate
administrative and technical security arrangements. First, the Organisation failed
to conduct or schedule any software updates, maintenance and/or security review
before the Incident. Past decisions by the Commission had stressed the need for
such security arrangements. The Organisation’s operating system and anti-virus
software, for example, were outdated and updated only after the Incident.

3. Second, the Organisation had failed to set out any data protection requirements or
responsibilities with the POS vendor whom the Organisation had engaged to
supply and install the POS, and relied on for system service issue. This meant that
the Organisation did not in fact engage the POS vendor to provide the necessary
maintenance support. As the Organisation continued to seek the POS vendor’s
assistance for any system service issue, it was also not entirely clear to the parties
concerned whether the POS vendor remained responsible for ensuring that the
POS system server was updated or patched. It should be reiterated that while an
organisation may engage other third-party service providers to provide the
2

necessary technical assistance and support, an organisation’s responsibility for
complying with its statutory obligations under the PDPA may not be delegated.1
Given the Organisation’s omission to engage any maintenance support prior the
Incident, the Organisation bore full responsibility for its failure to conduct or
schedule the necessary software updates, patches and security reviews.

4. In the circumstances, the Organisation is found to have breached section 24 of the
Personal Data Protection Act 2012 (the “PDPA”).

5. After the preliminary decision was issued, the Organisation submitted
representations requesting for a waiver of the financial penalty imposed. The
Commission considered the representations made, and took into account first, the
remediation efforts taken by the Organisation since the Incident, and its
commitment to invest in a better and more secure IT system, and second, the
adverse impact the COVID-19 pandemic had on the Organisation’s business
revenue. Nonetheless, as explained above, the onus remained on the Organisation
to put in place adequate security measures such as regular IT system
maintenance, patches and periodic security reviews.
.
6. Having considered all the circumstances in this case, the Deputy Commissioner
directs that the Organisation pays a financial penalty of S$5,000 within 30 days
from the date of the notice accompanying this decision, 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.

7. Finally, having considered the remedial actions taken by the Organisation, the
Commission will not issue any directions under section 48I of the PDPA.

See Re WTS Automotive Services Pte Ltd [2019] PDP Digest 317 at [14] and [23].

The following is the provision of the Personal Data Protection Act 2012 cited in the above summary:
Protection of personal data
24. An organisation shall protect personal data in its possession or under its control by making
reasonable security arrangements to prevent –
(a) unauthorised access, collection, use, disclosure, copying, modification, disposal or similar risks;
and
(b) the loss of any storage medium or device on which personal data is stored.

",Financial Penalty,ba5645fa0a7e61666bb1148c1c65700478353304
33,33,1,952,"A financial penalty of $12,500 was imposed on PINC for failing to put in place reasonable security arrangements to protect the personal data in its possession. Directions were also issued to PINC to develop and implement internal data protection policies and practices to comply with the PDPA and to ensure no copies of database were stored on employees' personal computers.","[""Accountability"", ""Protection"", ""Financial Penalty"", ""Directions"", ""Wholesale and Retail Trade"", ""No Policy""]",2022-05-19,https://www.pdpc.gov.sg/-/media/Files/PDPC/PDF-Files/Commissions-Decisions/Decision---PINC-Interactive-Pte-Ltd---04022022.pdf,"Accountability, Protection",Breach of the Accountability and Protection Obligations by PINC Interactive,https://www.pdpc.gov.sg/all-commissions-decisions/2022/05/breach-of-the-accountability-and-protection-obligations-by-pinc-interactive,2022-05-19,"PERSONAL DATA PROTECTION COMMISSION

[2022] SGPDPC 1

Case No. DP-2002-B5827

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

And

PINC Interactive Pte. Ltd.

… Organisation

DECISION

Page 1 of 9

PINC Interactive Pte. Ltd.
[2022] SGPDPC 1
Lew Chuen Hong, Commissioner — Case No. DP-2002-B5827
4 February 2022
Introduction
1

On 2 February 2020, the Personal Data Protection Commission (“the

Commission”) received feedback about a Twitter post dated 31 January 2020 which
revealed that the personal data of users of www.pincstyle.com had been exposed. The
tweet included a snapshot of the data (“the Incident”). The Commission commenced
investigations into the Incident thereafter.
Facts of the Case
2

The website www.pincstyle.com was created and managed by PINC Interactive

Pte. Ltd. (“the Organisation”) at the material time. Investigations revealed that
sometime in October 2019, a database comprising 252,813 records was accessed
and exfiltrated from the Organisation’s staging servers (the “Staging Database”). The
Staging Database is a synthetic database containing personal data of 3,916 actual
users, while the remaining 248,897 records were fake or “dummy” data modelled after
the real data. The synthetic database was used to facilitate development and testing
on the staging servers. The personal data from the 3,916 actual users that were
exposed in the Incident included the name, username, email address, contact number
(for some users) and a password hash. For completeness, the 3,916 user records in
the Staging Database is equivalent to 1.6% of the Organisation’s total database of
252,813 user records.

Page 2 of 9

Investigations revealed two likely causes of the Incident. First, the developers,

who are the Organisation’s employees, had retained a copy of the Staging Database
on their own personal devices, and the database was exfiltrated when the developers’
computers were compromised. The Organisation stated that while they had instructed
the developers to use strong passwords, the developers were left to manage the
security settings on their own computers, and only had antivirus software installed.
4

Second, unauthorised access may have occurred from May 2019 to October

2019 when the Organisation did not require authentication for the Application
Programming Interface (“API”) under testing (“Staging API”), which pointed to the
Staging Database containing the personal data of real users, despite the Staging
Database being accessible over the Internet. The Organisation only implemented
access key authentication from October 2019 onwards.
Remedial actions
5

Following the Incident, the Organisation took the following remedial actions:
a.

Updated the API with new authentication keys;

Limited the access of authentication keys to only the senior developers;

A password reset was initiated for affected users via email; and

Developers were instructed to delete their local copy of the Staging
Database and scan their own computers for malware.

Findings and Basis for Determination
Whether the Organisation contravened the Protection Obligation
6

Section 24 of the Personal Data Protection Act 2012 (“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,
Page 3 of 9

disclosure, copying, modification, disposal or similar risks (the “Protection
Obligation”). For the reasons set out below, the Organisation failed to implement
reasonable security arrangements to protect the personal data in the Staging
Database.
7

Firstly, the Organisation had failed to accord adequate protection to the

personal data by allowing their employees, i.e. the developers, to store local copies of
the Staging Database in their own personal devices, without implementing any
additional security requirements. Allowing their employees to store the Staging
Database in their own personal devices constituted a breach of the Protection
Obligation, given that the Staging Database did not merely contain purely synthetic
data, but also the personal data of real users.
8

Secondly, the Organisation was also in breach of the Protection Obligation as

it merely instructed its employees not to use weak passwords on their personal
devices, and left it to each individual employee to decide if and what level of security
measures ought to be implemented on their own personal devices to protect the
personal data. Indeed, even though the developers had purportedly installed antivirus
software on their own personal devices, the Organisation was unable to provide the
product name, version, or the frequency of the antivirus updates that the developers
supposedly implemented on their end when questioned.
9

In Learnaholic Pte. Ltd.1, the Organisation was found in breach of section 24 of

the PDPA as the personal data affected had been sent to and stored in the work email
account belonging to the Organisation’s representative in an unencrypted form. After
completing the task at hand, the representative failed to delete the email containing
the personal data that he received. Instead, the representative kept the email
containing the personal data, in case he needed it in future. As a result, the hacker
had free rein to the personal data affected once he obtained access to the email

1 [2019] SGPDPC 31.

Page 4 of 9

account. In a similar vein, the Organisation here has failed to adopt adequate security
measures when it simply allowed its employees to retain a copy of the Staging
Database on their own personal devices, without putting any thought to the security
measures that ought to be implemented to protect the personal data.
10

Finally, while we appreciate that the Organisation wanted the Staging API to

mirror the production environment, it was not a reasonable “protection” measure to
commingle synthetic data with the personal data belonging to real users, without
processing the personal data of the real users before doing so, as this meant that the
Staging Database contained the data of real users. Having decided to use personal
data belonging to real users in the Staging Database, the Organisation has breached
the Protection Obligation by failing to require authentication before the Staging API
could be accessed. If the Organisation’s intention was not to require authentication for
the Staging API, the Organisation should have chosen to use only synthetic data in
the Staging Database. In How to Guard Against Common Types of Data Breaches
(the “Handbook”),2 the Commission identified the five most common gaps in ICT
system management and processes, and observed at page 11 of the Handbook that:
“Out of convenience, many organisations use production data for system
testing in their test environments. But as test environments tend to be much
less secured, there is a high risk of data breach in a test environment.”
11

In the Handbook, the Commission explained that synthetic data can be

generated either from scratch using commercial tools or by anonymising production
data, and recommended that organisations can create synthetic data (i.e. fake
personal data or data anonymised from real data) for development and testing
purposes in non-production environments instead of using real data.

2 https://www.pdpc.gov.sg/news-and-events/announcements/2021/05/handbook-on-how-to-guard-

againstcommon-types-of-data-breaches-now-available

Page 5 of 9

In this case, the Organisation could have chosen to use 100% synthetic data

or anonymise the personal data before using them if it did not wish to require
authentication for the Staging API. In light of the above, we are also of the view that
the Organisation breached the Protection Obligation by using personal data belonging
to real users in the Staging Database, but failing to require authentication before the
Staging API could be accessed.
Whether the Organisation contravened the Accountability Obligation
13

Section 12(a) of the PDPA requires an organisation to develop and implement

policies and practices that are necessary for the organisation to meet its obligations
under the PDPA (the “Accountability Obligation”).
14

The Organisation admitted that they did not have any data protection policies

or practices in place for their “non-technical” employees, who have access to “public
user data”. In its reply, the Organisation drew a distinction between its “technical” and
“non-technical staff”, and stated that for the “technical” staff, the data protection
policies in place extended to the Organisation’s team lead providing a briefing to the
“technical” staff of the system, rules for branch creation and the code standard during
onboarding. The information provided by the Organisation to its “technical” staff, during
their onboarding, serves merely to facilitate the performance of these employees’ core
duties, and cannot be equated with or amount to data protection policies or practices.
15

Indeed, the Organisation’s reply reflects a lack of understanding of what data

protection policies and processes seek to achieve and implement. We have previously
stressed the critical role that data protection policies and practices play in increasing
awareness and ensuring accountability of an organisation’s obligations under the
PDPA in Re Aviva Ltd3. We also explained in Re Singapore Cricket Association4 that
data protection policies and practices ensure that employees will be able to better

3 [2018] PDP Digest 245 at [32].
4 [2019] PDP Digest 270 at [19].

Page 6 of 9

protect personal data when they are first able to recognise a matter as one involving
data protection.
16

Given the Organisation’s reply, it follows that the Organisation did not in fact

have any data protection policies or processes in place to guide their employees on
how to comply with the PDPA in carrying out their work functions. The Organisation
has therefore breached the Accountability Obligation.
The Commissioner’s Directions
17

In determining whether to impose a financial penalty on the Organisation

pursuant to section 48J(1) of the PDPA, and if so, the amount of such financial penalty,
the factors listed at section 48(6) of the PDPA were taken into account, as well as the
following aggravating and mitigating factors:
Aggravating Factors
(a)

The Organisation allowed its employees to keep local copies of the

Staging Database on their personal devices, without considering and
undertaking any security measures needed to protect the personal data of real
users;
Mitigating Factors
(b)

The Organisation was cooperative in the course of investigations and

had provided prompt responses to PDPC’s requests for information; and
(c)

The Organisation was implemented remedial actions to address the

Incident.
18

In the course of settling this decision, the Organisation made representations
on the amount of financial penalty that the Commissioner intended to impose.

Page 7 of 9

The Organisation raised the following factors for the Commissioner’s
consideration:
(a)

The Organisation had engaged an external consultancy firm to ensure

that its obligations under the PDPA are upheld to the highest standards with
periodic audits, training and risk assessments; and
(b)

The Organisation was incorporated in 2018 and is still a relatively young

company. Since its inception, it had been suffering significant losses in its
operation.
19

Having considered the Organisation’s representations, as well as all the

relevant factors of this case, the Commissioner hereby decided to impose a reduced
financial penalty of $12,500 on the Organisation. The quantum of financial penalty has
been calibrated and reduced after due consideration of the Organisation’s financial
circumstances, bearing in mind that any financial penalty imposed should not be
crushing or cause undue hardship on organisations.
20

Taking into account all the relevant facts and circumstances, the Commissioner

hereby:
(a)

Requires the Organisation to pay a financial penalty of $12,500 within

30 days from the date of the relevant notice accompanying this decision, 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)

Directs the Organisation to:
(i)

Develop and implement internal data protection policies and

practices to comply with the PDPA within 60 days of the relevant
direction accompanying this decision;

Page 8 of 9

(ii)

Ensure that no local copies of the database are stored on the

personal computers of any employees (including both developers and
senior

developers)

within

days

the

relevant

direction

accompanying this decision; and
(iii)

To notify the Commission within 1 week of the completion of this

direction.
21

Although the Commissioner has imposed a lower financial penalty on the

Organisation in this case, the financial penalty was arrived at after considering the
dismal state of the Organisation’s finances, and should be confined to the specific
facts of this case.

YEONG ZEE KIN
DEPUTY COMMISSIONER
FOR COMMISSIONER FOR PERSONAL DATA PROTECTION

Page 9 of 9

","Financial Penalty, Directions",d2cda7ac80cc4638223955ef382304ee06a36b98
34,34,1,952,"A financial penalty of $24,000 was imposed on Lovebonito for failing to put in place reasonable security to protect personal data in its possession. The incident resulted in the personal data being accessed and exfiltrated.","[""Protection"", ""Financial Penalty"", ""Wholesale and Retail Trade"", ""Password policy""]",2022-05-19,https://www.pdpc.gov.sg/-/media/Files/PDPC/PDF-Files/Commissions-Decisions/Decision--Lovebonito-Singapore-Pte-Ltd--21022022.pdf,Protection,Breach of the Protection Obligation by Lovebonito,https://www.pdpc.gov.sg/all-commissions-decisions/2022/05/breach-of-the-protection-obligation-by-lovebonito,2022-05-19,"PERSONAL DATA PROTECTION COMMISSION

[2022] SGPDPC 3

Case No. DP-1912-B5484

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

And

Lovebonito Singapore Pte. Ltd.
… Organisation

DECISION

Lovebonito Singapore Pte. Ltd.

[2022] SGPDPC 3
Lew Chuen Hong, Commissioner — Case No. DP-1912-B5484
21 February 2022

Introduction
1

On 12 December 2019, Lovebonito Singapore Pte. Ltd (the “Organisation”)

informed the Personal Data Protection Commission (“Commission”) that one of its IT
systems had been hacked, and that the personal data of 5,561 of its customers had
been accessed and exfiltrated by a malicious actor (the “Incident”). The Commission
subsequently received two separate complaints from individuals affected in the
Incident.
Facts of the Case
2

The Organisation operates an e-commerce platform (the “Website”) retailing

clothing and accessories. At the material time, the Organisation employed, amongst
others, two third-party solutions to manage the Website. First, the Organisation
employed Magento Cloud, a cloud-based service, to host and run the Website.
Magento Cloud includes the Magento Content Management System (“Magento
CMS”), an open-source e-commerce management software, which the Organisation
used to change and update the Website. Second, the Organisation used a payment
platform offered by Adyen N.V. (“Adyen”) to facilitate credit card payments on the
Website. When a customer indicated that they intended to pay for their purchases via
credit card, Adyen’s platform would load directly from their servers as a frame within
the “checkout” page of the Website (the “Checkout Page”).
3

Customers would then input the below details into Adyen’s frame, and Adyen

would directly collect these details and process the credit card payment:
(a)

Full credit card number;

(b)

Expiry date of the credit card;
2

(c)

The CVV number of the credit card; and

(d)

Customer’s billing address

(collectively, the “Credit Card Data”)
4

Once Adyen has processed the credit card payment, it would send some (but

not all) of the Credit Card Data to the Organisation, namely:
(a)

The last 4 digits of the credit card number;

(b)

Expiry date of the credit card;

(c)

Adyen’s payment reference; and

(d)

Billing address.

(collectively, the “Partial Credit Card Data”)
5

The Organisation would then store the Partial Credit Card Data together with

other details collected by the Organisation for the purposes of processing the order
(the “Order Data”). The Order Data comprised the following personal data of the
Organisation’s customers:
(a)

First name;

(b)

Last name;

(c)

Shipping address;

(d)

Date of birth (optional);

(e)

Phone number;

(f)

Email address;

(g)

Order details;

(h)

Payment type: Paypal, credit card (i.e., Visa, Mastercard), bank transfer;

and
3

(i)

If payment was made via:
(i)

Credit Card: Partial Credit Card Data; or

(ii)

Paypal: the email address associated with the Paypal account (if

the customer in question completed the transaction using his/her Paypal
account).
6

On or around 22 November 2019, the Organisation noted a high drop in credit

card authorisations for payments via Adyen’s platform and began investigating the
issue with Adyen. It was discovered that the Checkout Page had been configured to
load an incorrect form replacing Adyen’s frame on the Checkout Page. This incorrect
form had not been submitted via Magento CMS or validated by any of the
Organisation’s employees, and the Organisation was unable to determine the source
of the form. The next day, the Organisation implemented a fix to replace the incorrect
form with the correct one, in order to allow the processing of credit card payments to
resume through Adyen’s platform, while root cause analysis was undertaken.
7

Subsequently, on or around 9 December 2019, the same issue resurfaced. As

a precaution, the Organisation turned off the credit card payment functionality on the
Checkout Page, and continued investigations into the issue with Adyen, Magento, and
subsequently a private forensic investigator (“PFI”).
8

Based on these further investigations, it was concluded that:
(a)

One of the Organisation’s Magento CMS accounts with administrator

privileges was likely to have been compromised (the “Compromised
Account”);
(b)

The Compromised Account was likely used to modify the Checkout

Page to load and execute an unauthorised JavaScript code each time the
Checkout Page was loaded (“the Unauthorised Code”);
(c)

The Unauthorised Code caused the Credit Card Data intended to be

sent to Adyen to be intercepted and exfiltrated to the malicious actor instead
(explaining the drop in credit card transactions); and

(d)

The Compromised Account was also used by the malicious actor to

access and exfiltrate Order Data from the Website via unauthorised Application
Programming Interface (“API”) calls to Magento CMS.
9

The personal data of a total of 5,561 customers was accessed and exfiltrated

in the Incident of which:
(a)

4,817 customers had only their Order Data affected;

(b)

188 customers had only their Credit Card Data affected: and

(c)

556 customers had both their Order Data and Credit Card Data affected.

Remedial actions
10

Following the Incident, the Organisation:
(a)

Removed the Unauthorised Code from the Website;

(b)

Notified affected customers of the Incident and offered a complimentary

credit monitoring service;
(c)

Reset the passwords for all Magento CMS user accounts;

(d)

Implemented a new password policy and two-factor authentication for all

Magento CMS user accounts;
(e)

Implemented session management;

(f)

Reviewed its Magento CMS access permissions, refined the scope of

roles, and limited the number of users with Magento CMS accounts;
(g)

Implemented a remote access virtual private network;

(h)

Implemented endpoint protection;

(i)

Implemented a custom script to monitor for JavaScript injections;

(j)

Set up API “whitelisting” to restrict network access to only approved IP

addresses;
5

(k)

Implemented a monitoring script to trigger alerts whenever there was a

request from a non-trusted domain;
(l)

Conducted two external penetration tests;

(m)

Upgraded its version of Magento CMS to fix a security vulnerability found

in the version it was using; and
(n)

Implemented CAPTCHA on its Website to deter brute-force attacks.

Findings and Basis for Determination
11

As a preliminary point, both the Order Data and the Credit Card Data

constituted personal data as defined by section 2(1) of the Personal Data Protection
Act 2012 (“PDPA”) 1 . In respect of the Order Data, distinct individuals could be
identified from such data. In respect of the Credit Card Data, although such data could
not identify any individual on its own, it could identify individuals together with other
data that the Organisation had access to (viz., the Order Data).
Whether the Organisation had contravened section 24 of the PDPA
12

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 “Protection Obligation”). While the Organisation did not
have possession of the Credit Card Data (i.e. because it did not collect or store the
Credit Card Data), the Protection Obligation nonetheless applied, as it had control over
the Credit Card Data.
13

As highlighted in Re AIG Pacific Insurance Pte. Ltd. [2018] SGPDPC 8 at [18]:
“While there is no definition of “control” in the PDPA, the meaning of control
in the context of data protection is generally understood to cover the ability,

1 Under section 2(1) of the PDPA, “personal data” is defined as “data, whether true or not, about an

individual who can be identified (a) from that data; or (b) from that data and other information to which
the organisation has or is likely to have access”.

right or authority to determine (i) the purposes for; and/or (ii) the manner
in which, personal data is processed, collected, used or disclosed.”
14

In this case, the Organisation made the decision to deploy Adyen’s HTML code

within a frame on the Checkout Page, and this decision directed the manner in which
the Credit Card Data was collected, processed and disclosed via the Website. Thus,
even though the Credit Card Data was sent to Adyen directly without first being
collected and stored by the Organisation, the Organisation had control over how the
Credit Card Data was collected, and the additional processing into a format which was
then transmitted to Adyen. The Organisation exercised such control by implementing
(or deploying) Adyen’s HTML code within a frame on its Checkout Page.
15

The application of the Protection Obligation to the Order Data is more straight

forward as this dataset was collected and stored by the Organisation. As the
Organisation had possession of the Order Data and control over the Credit Card Data,
the Protection Obligation applied in respect of both datasets.
16

In assessing the reasonableness of the Organisation’s security arrangements,

the fact that the data within its control included personal data of a financial nature (i.e.
the Credit Card Data) was considered highly relevant. As highlighted in the
Commission’s previous enforcement decisions, stronger security measures are called
for when protecting sensitive personal data because of the potential harm that may
befall an individual from unauthorised use of such data.2
17

For the reasons set out below, the Organisation failed to put in place such

reasonable security arrangements to protect the Order Data and Credit Card Data.
Inadequate password policy
18

A robust password policy is a key security measure that an organisation must

have in place to ensure that its IT systems are not vulnerable to common hacking
attempts such as brute force attacks. As noted in Re (1) The Cellar Door Pte Ltd; (2)
Global Interactive Works Pte. Ltd. [2016] SGPDPC 22 (at [30(d)]):
2 Credit Counselling Singapore [2017] SGPDPC 18 at [25]; PeopleSearch Pte. Ltd. [2019] SGPDPC 47

at [10].

“… The need to have a strong password is fundamental to the security of
the database system. Weak passwords increase the chances of an
intruder cracking the password and gaining full access to the database
system, and, more importantly, the personal data stored therein.”
19

Magento CMS had several default security settings and the Organisation

confirmed that it had adopted these default settings as its password policy for its
Magento CMS accounts (the “Magento Password Policy”). While default settings of
the Magento Password Policy on password length, and the implementation of a
lockout after a number of failed login attempts were in line with good practices
suggested in the Commission’s Guide to Securing Personal Data in Electronic Medium
(the “Guide”)3, more robust and stringent measures were required.
20

First, the Magento Password Policy did not mandate periodic changes of

passwords as part of the default settings, despite the availability of this functionality in
Magento CMS. As stated in paragraph (g) of Table 4 in the Guide:
“Users are required to change their passwords regularly. The frequency
should be based on the risk of damage to the individual if the data is
compromised.”
[Emphasis added.]
21

Second, the default settings of the Magento Password Policy did not require

the Organisation’s employees to refrain from using easily-guessable passwords. As
highlighted in Re Chizzle Pte Ltd [2020] SGPDPCR 1, a password that complies with
an organisation’s rules on password complexity in form, could still be regarded as a
weak password if it incorporated components such as the organisation’s name. In this
respect, the Organisation ought to have complemented the technical Magento
Password Policy with a written password policy. Both written and technical policies
reinforce each other. Technical policies alone may not ensure that users refrain from
incorporating easily-guessable words or phrases such as their user name, real name,

3 Published on 8 May 2015, and revised on 20 January 2017. The Guide has recently been replaced

by a new Guide to Data Protection Practices for ICT Systems. All references to the Guide in these
grounds are to the 2017 edition.

birth date, or the organisation’s name in the password. In this case, the password of
the Compromised Account – “ilovebonito88” – incorporated the Organisation’s name,
which made it easy to guess and vulnerable to brute force attacks.
22

For these reasons, the out-of-the-box default settings of the Magento Password

Policy was not sufficiently robust for the Organisation’s needs and failed to meet the
standard of being a reasonable security arrangement under the Protection Obligation.
Weaknesses in the Organisation’s host, network, remote access, and webpage
security
23

There were other significant weaknesses in the Organisation’s IT systems

identified by the PFI that could have also been exploited by malicious actors to gain
privileged access to Magento CMS:
(a)

The Organisation’s system allowed insecure remote access, with no /

limited system logging and no / limited system hardening;
(b)

The Organisation’s system was not patched / maintained;

(c)

There was a lack of security monitoring for the Organisation’s network;

(d)

There was a lack of network ingress and egress filtering of the

Organisation’s network to examine network traffic;
(e)

There was a lack of monitoring and logging of remote access connection

attempts; and
(f)
24

There was improper access control in respect of Magento CMS.

The above weaknesses indicated that the IT security measures implemented

by the Organisation were inadequate in managing the risks of unauthorised access
and exfiltration of the Credit Card Data and Order Data.
25

The above security measures did not meet the standard of reasonableness,

and the Commissioner finds the Organisation in breach of the Protection Obligation in
this regard.
9

The Preliminary Decision
26

In determining whether to impose a financial penalty on the Organisation

pursuant to section 48J(1) of the PDPA, and if so, the amount of such financial penalty,
the factors listed at section 48J(6) of the PDPA were taken into account, as well as the
following mitigating factors:
Mitigating Factors
(a)

The Organisation took prompt remedial actions following discovery of

the Incident, including notifying affected individuals of the breach; and
(b)
27

The Organisation was cooperative during the investigations.

In the preliminary decision, the Organisation’s failure to implement two-factor

authentication (“2FA”) to secure privileged access to Magento CMS was also
considered as an instance of breach of the Protection Obligation – this is discussed
further below at [33] to [36]. Having considered all the relevant factors of this case, the
preliminary financial penalty was set at $29,000.
28

The Organisation was notified of the preliminary decision by way of the

Commission’s letter dated 21 June 2021 and was invited to make representations on
the same.
Representations Made by the Organisation
29

On 12 July 2021, the Organisation made representations that it ought not be

found in breach of section 24 of the PDPA because:
(a)

The Organisation’s measures to safeguard its administrative accounts

were reasonable; and
(b)

It could not be conclusively determined that the weaknesses in the

Organisation’s IT systems had directly caused the Incident.

Representations on reasonableness of security measures for Magento CMS
30

The Organisation represented that its security measures for Magento CMS

were commensurate with the risks associated with a potential data breach, as:
(a)

Magento CMS was only intended to collect and store the Order Data,

which was less sensitive personal data; and
(b)

The risk of compromise to the more sensitive Credit Card Data via

Magento CMS was assessed to be relatively low, where the Credit Card Data
was collected directly by Adyen via a frame on the Website’s Checkout Page
loaded directly from Adyen’s server, without such data being transmitted to the
Organisation.
31

The Organisation’s representations in this regard are not accepted. While it is

accepted that the Credit Card Data was not transmitted to the Organisation and was
collected directly by Adyen via the Checkout Page of the Website, access and
changes to the Website were in turn managed and carried out by the Organisation via
Magento CMS. There was therefore a foreseeable risk that unauthorised access to
the Website using one of the Organisation’s Magento CMS administrative accounts
could lead to unauthorised changes to the Checkout Page, adversely affecting its
intended function and performance. Such unauthorised changes could include the
insertion of a malicious code to intercept and exfiltrate the Credit Card Data collected
via the Checkout Page.
32

The Credit Card Data was collected via the Website, and it was for the

Organisation to secure the Website against unauthorised changes in order to protect
the Credit Card Data. Put differently, the Organisation’s Protection Obligation
extended over the Website in its entirety, including the Checkout Page. The
Organisation was therefore incorrect in assessing that there was a low risk of
compromise to the Credit Card Data via Magento CMS. The security measures
implemented by the Organisation for Magento CMS and in its databases and systems
did not constitute reasonable security measures, having regard to the risks in the
context of the sensitivity and volume of the personal data in its possession and/or
control.
11

Representations on failure to enable 2FA for administrative accounts
33

In the present case, 2FA was available as an “out-of-the-box” feature in

Magento CMS. In the preliminary decision, the Organisation’s failure to enable 2FA in
Magento CMS was found to be another instance of its breach of the Protection
Obligation.
34

The Organisation represented that 2FA was not an out-of-the-box feature in

Magento CMS version 2.3.2, which the Organisation was using at the time of the
Incident, and that the option to activate 2FA was only available in Magento CMS
version 2.4, via a third-party vendor (GitHub) module “MSP_TwoFactorAuth”.
However, according to publicly available Magento version 2.3.x user guides – and
contrary to the Organisation’s representations – 2FA was already a feature available
on Magento CMS version 2.3.2, albeit at that version, 2FA was not enabled by default.
35

The Organisation also represented that even if 2FA had been implemented, it

would not have prevented the Incident as the “2FA functionality in Magento CMS
version 2.4 would only have restricted unauthorised access via the graphical user
interface (“GUI”) of Magento CMS” and that “(…) 2FA would not have prevented API
calls to Magento CMS, which was the actual mechanism by which the Organisation’s
website was modified during the Incident”. In an investigation summary report
prepared by Magento in respect of the Incident, Magento did not find any evidence of
changes made to the Organisation’s website made via the GUI, and concluded that it
was “more likely” that the administrative account belonging to [redacted] was used “to
make modifications and access information via API requests”.
36

After careful consideration of the Organisation’s representation, it is decided

that the benefit of doubt ought to be given to the Organisation on the preliminary
findings and its representations concerning the implementation of 2FA for two reasons.
First, the external actor accessed and modified the Organisation’s Website via API
calls to Magento CMS (as opposed to via the GUI of Magento CMS), which made the
attack a sophisticated one. Second, the Organisation’s failure to consider enabling the
out-of-the-box 2FA functionality within Magento CMS was but one of several instances

supporting the finding of its breach of the Protection Obligation. The finding of breach
is maintained on the basis of other instances of breach.
Representations on other weaknesses in IT systems
37

The Organisation’s representation that it cannot be conclusively determined

that the weaknesses in its IT systems had directly caused the Incident (see [29(b)]
above) is rejected. The Commission’s role is not limited to investigating the immediate
or proximate cause of the data breach although this may have been one of the lines
of inquiry. The Commission’s investigations found that other weaknesses in the
Organisation’s IT systems posed risks to personal data in the Organisation’s
possession and/or control, including Order Data that it collected and processed. The
Organisation ought to have implemented reasonable security measures to manage
these risks. In failing to do so, the Organisation breached the Protection Obligation.
Other representations seeking reduction in financial penalty
38

The Organisation also made representations for a reduction in the financial

penalty on the basis that:
(a)

It was inaccurate to state the number of affected individuals as 5,561, as

only 4,474 individuals in Singapore were affected;
(b)

The Organisation had admitted to the Incident at first instance;

(c)

The Organisation had promptly alerted customers of the Incident and

offered a complimentary credit monitoring service;
(d)

There were no other data breach incidents reported apart from the

Incident; and
(e)

The Organisation had in place existing security measures to guard

against unauthorised access to databases and systems.
39

The Organisation’s attempt to confine the number of affected individuals in the

Incident to those in Singapore is misconceived and is rejected. The PDPA requires
organisations to protect all personal data in their possession or control, and does not
13

draw distinctions between the personal data of individuals in Singapore and outside of
Singapore.
40

As to the factors raised by the Organisation at [38(b)] to [38(e)] above, these

had already been taken into account in the assessment of the appropriate financial
penalty to be imposed.
41

In the preliminary decision, the preliminary financial penalty was derived

considering, inter alia, the gravity of the Organisation’s breach of the Protection
Obligation in failing to consider implementing 2FA, which was available out-of-the-box.
As the Organisation’s representations that 2FA may not have prevented the Incident
are accepted, the gravity of the Organisation’s breach is lessened, and it follows that
the quantum of the financial penalty should also be moderated.
42

Having said that, the Organisation’s breach included more fundamental

failures, such as failing to implement a robust password policy and to refrain the
Organisation’s employees from using easily-guessable passwords. Regardless of
whether 2FA would have prevented the specific vector of attack adopted by the threat
actor, the harm caused to data subjects in the Incident remains the same.
43

For the above reasons, the Commissioner is of the view that based on the

representations made by the Organisation, the preliminary financial penalty of $29,000
should be reduced to $24,000. The Commissioner hereby requires the Organisation
to pay a financial penalty of $24,000 within 30 days from the date of the notice
accompanying this decision, failing which interest at the rate specified in the Rules of
Court in respect of judgment debts would accrue and be payable on the outstanding
amount of such financial penalty until the financial penalty is paid in full.
44

In view of the remedial actions already been taken by the Organisation, no

further directions need be issued to the Organisation.

Two- or multi-factor authentication as mandatory baseline standard for
administrative accounts with privileged access to systems that host or process
sensitive personal data
45

As 2FA and multi-factor authentication (“MFA”) become more broadly available,

the adoption of these tools should become the norm, at least for accounts with
administrative privileges.
46

Recently, the Commission released a handbook on common causes of data

breaches (How to Guard Against Common Types of Data Breaches4, at page 13) that
recommends 2FA / MFA for all administrator access to systems holding large volumes
/ sensitive personal data:
“Have stronger requirements for some administrative accounts (e.g.
a complex password or 2-Factor Authentication (2FA) / Multi-Factor
Authentication (MFA)). With 2FA/MFA in place, access to administrative
accounts would involve additional round (s) of authentication, such as a
temporary code sent securely to the administrator’s mobile phone. Hence,
the use of a stolen password alone will not be enough to breach an
account. This is important for administrative accounts to systems
that hold large volumes of personal data, or personal data of a
confidential or sensitive nature (e.g. financial or health records), where
a breach of such data could result in adverse impact to the affected
individuals.”
[Emphasis added]
47

The Commission’s recent Guide to Data Protection Practices for ICT Systems5

at page 16 similarly recommends using “a one-time password (“OTP”) or 2FA/MFA for
admin access to sensitive personal data records or large volumes of personal data”,
as part of the authentication and authorisation processes in ICT systems.

https://www.pdpc.gov.sg/-/media/files/pdpc/pdf-files/resource-for-organisation/how-to-guard-againstcommon-types-of-data-breaches-handbook.pdf
5 https://www.pdpc.gov.sg/-/media/Files/PDPC/PDF-Files/Other-Guides/Tech-Omnibus/How-toGuard-Against-Common-Types-of-Data-Breaches-Handbook.pdf

This is the baseline standard that the Commission will apply in future cases.

This is not a standard that was adopted lightly, but after industry consultation and
considering developments domestically and internationally.
49

In recent domestic cases, the Commission has observed that 2FA was

implemented by the Organisations involved as part of voluntary remedial measures:
(a)

In MSIG Insurance (Singapore) Pte Ltd and Globalsign.in Pte Ltd [2019]

SGPDPC 43, an administrative account for the organisation’s email marketing
system was hacked, resulting in spam emails being sent to over 350,000
individuals. The organisation was found in breach of the Protection Obligation
for not implementing a proper password policy or carrying out periodic security
scanning. As part of voluntary remedial measures, the organisation
implemented 2FA for its administrative accounts.
(b)

In Ncode Consultant Pte Ltd [2019] SGPDPC 11, students exploited

vulnerabilities in a school’s administration system (which had been developed
by the investigated organisation), obtained a teacher’s login credentials, and
modified examination results. The organisation was found in breach of the
Protection Obligation for insecure coding which resulted in the exploited
vulnerabilities. As part of voluntary remedial measures, the organisation
implemented 2FA for the teachers’ accounts.
(c)

In Learnaholic Pte Ltd [2019] SGPDPC 31, an employee of the

investigated organisation (a school IT vendor) had his email account hacked,
resulting in unauthorised access to a large number of students’ personal data
including medical information. The organisation was found in breach of the
Protection Obligation for negligently leaving one of the school’s servers
exposed to the Internet, leaving credentials to the employee’s email account in
the exposed server, and storing students’ personal data in the employee’s email
account in an unencrypted form. The organisation implemented 2FA for its
employees’ email accounts as part of voluntary remedial measures.

A review of guidance and cases from foreign jurisdictions shows that

implementing 2FA (or similar arrangements) to secure privileged access to sensitive
data is by now a reasonable and industry-standard practice:
(a)

United Kingdom. In two separate guidance notes, i.e. “Multi-factor

authentication for online services”6 and “10 Steps to Cyber Security – Identity
and access management”7, UK’s National Cyber Security Centre advises that
MFA be enabled for all accounts with administrative privileges.
(b)

Canada. The Privacy Commissioner of Canada (“PCC”) has cited the

failure to implement MFA to secure all remote administrative access as a
significant data protection failing in the Joint Investigation of Ashley Madison by
the

Privacy

Commissioner

Canada

and

the

Australian

Privacy

Commissioner/Acting Australian Information Commissioner 8 , where the
personal data of 36 million customers of the investigated organisation (including
sensitive personal and financial data) was published online. In a subsequent
note on takeaways from the investigation 9 , the PCC described MFA as a
commonly recommended industry practice for controlling remote administrative
access, and recommended that MFA be so implemented in all such cases.
(c)

Australia. The “Australian Government Information Security Manual”, a

cybersecurity framework for organisations published by the Australian Cyber
Security Centre 10 , recommends that MFA be used to authenticate all (i)
privileged users, (ii) positions of trust, (iii) users of remote access solutions, and
(iv) users with access to important data repositories. The Office of the
Australian Information Commissioner, in its “Guide to securing personal
information”11 recommends that MFA be employed in circumstances that may

6 https://www.ncsc.gov.uk/guidance/multi-factor-authentication-online-services
7 https://www.ncsc.gov.uk/collection/10-steps/identity-and-access-management
8 Joint Investigation of Ashley Madison by the Privacy Commissioner of Canada and the Australian

Privacy Commissioner/Acting Australian Information Commissioner (PIPEDA Report of Findings
#2016-005,
22
August
2016)
<https://www.priv.gc.ca/en/opc-actions-anddecisions/investigations/investigations-into-businesses/2016/pipeda-2016-005>
9
https://www.priv.gc.ca/en/privacy-topics/business-privacy/safeguards-and-breaches/safeguardingpersonal-information/2016_005_ta/
10 https://www.cyber.gov.au/acsc/view-all-content/guidance/authentication-hardening
11 https://www.oaic.gov.au/privacy/guidance-and-advice/guide-to-securing-personal-information/

pose a higher security risk, such as remote access to a system or access to
sensitive or restricted personal information.
51

Henceforth, the Commission adopts the following tiered approach:
(a)

First, 2FA / MFA should be implemented as a baseline requirement for

administrative accounts to systems that hold personal data of a confidential or
sensitive nature, or large volumes of personal data: see [46]-[47] above. Failure
to do so can ipso facto amount to a breach, unless the organisation can show
that its omission is reasonable or implementation of 2FA is disproportionate.
(b)

Second, remote access by privileged accounts to information systems

that host confidential or sensitive personal data, or large volumes of personal
data, should a fortiori be secured by 2FA / MFA. The risks concerning remote
access are higher, thus the expectation to implement 2FA / MFA will
correspondingly increase.
(c)

Third, organisations using IT systems to host confidential or sensitive

personal data, or large volumes of personal data, are expected to enable and
configure 2FA / MFA, if this is a feature that is available out-of-the-box.
Omission to do so may be considered an aggravating factor.

YEONG ZEE KIN
DEPUTY COMMISSIONER
FOR COMMISSIONER FOR PERSONAL DATA PROTECTION

",Financial Penalty,89b55bd8d0fb6740006b25908bf6eba6b220b5c5
35,35,1,952,Royal Caribbean Cruises (Asia) was found not in breach of the PDPA in relation to a coding error in a business software which resulted in emails containing personal data being sent to unintended recipients.,"[""Protection"", ""Not in Breach"", ""Arts, Entertainment and Recreation"", ""Software"", ""Unintended recipient""]",2022-05-19,https://www.pdpc.gov.sg/-/media/Files/PDPC/PDF-Files/Commissions-Decisions/Decision--Royal-Caribbean-Cruises-Asia-Pte-Ltd--130819.pdf,Protection,No Breach of the Protection Obligation by Royal Caribbean Cruises (Asia),https://www.pdpc.gov.sg/all-commissions-decisions/2022/05/no-breach-of-the-protection-obligation-by-royal-caribbean-cruises,2022-05-19,"PERSONAL DATA PROTECTION COMMISSION
Case No. DP-1804-B1931
In the matter of an investigation under section 50(1) of the
Personal Data Protection Act 2012
And
Royal Caribbean Cruises (Asia) Pte. Ltd.

SUMMARY OF THE DECISION
1. On 5 April 2018, the Personal Data Protection Commission (“Commission”)
commenced investigation against Royal Caribbean Cruises (Asia) Pte Ltd (the
“Organisation”) after receiving a complaint from a member of the public (the
“Complaint”). The complainant stated that she had received the personal data of
unrelated individuals in an email payment reminder sent by the Organisation.

2. Investigations revealed that, from 8 February 2018 to 4 April 2018, the personal
data of 526 individuals were inadvertently disclosed to other unrelated members of
the public via unintended email payment reminders (the “Data Breach Incident”).
The personal data disclosed included booking IDs, ship codes, sailing dates,
names, net amounts due, amounts paid, balance due and the balance due date
(the “Affected Personal Data”).

3. The Organisation is part of the Royal Caribbean Group, and is the wholly owned
subsidiary and data intermediary of the USA-based Royal Caribbean Cruises Ltd

(Liberia) (“RCL”). It is responsible for the following business functions on behalf of
RCL:
(a) Conducting sales and marketing activities on behalf of the cruise ship
operators of the Royal Caribbean Group, including RCL;
(b) Taking cruise bookings from Singapore-based customers of RCL;
(c) Administering a loyalty membership programme on behalf of RCL; and
(d) Collecting payments from Singapore-based customers of RCL who made their
bookings via walk-in, roadshows and online bookings at the Royal Caribbean
Group’s Singapore website.

4. RCL’s branch office in the Philippines (“RCL Philippines”) provides IT support to
entities within the Royal Caribbean Group, and does not have a separate legal
identity from RCL. On 1 January 2017, the Organisation entered into an operative
intercompany agreement with RCL Philippines for the provision of IT support and
customer services support. Such services included providing technical support for
the business software applications and services used by the Organisation.

5. As part of its business functions, the Organisation would send its Singapore
customers email payment reminders prior to the commencement of their cruises.
On 8 February 2020, the Organisation automated this business function through a
business software enterprise operated by RCL Philippines (the “Hyperion
System”), which would generate pre-programmed emails to individual customers
to remind them of outstanding bill amounts (the “Direct Payment Reminder”).
Concurrently, a collated list of the customers (together with other personal data)
who received the Direct Payment Reminder would be generated and sent via email

to the Organisation (“Collated Payment Reminder”). Both the Direct Payment
Reminder and Collated Payment Reminder were automatically generated on a
scheduled frequency and sent to the customers and Organisation by the Hyperion
System without any manual intervention from the Organisation (the “Automated
Payment Reminder System”).

6. The Automated Payment Reminder System had been successfully implemented in
other countries, and RCL Philippines put in place the following process to handle
requests from Royal Caribbean Group entities related to the Hyperion System:
(a) RCL Philippines would receive a request from respective Royal Caribbean
entity for a new process to be implemented in the Hyperion System;
(b) RCL Philippines would review the scope of the request and configure the
Hyperion System;
(c) RCL Philippines would then run a test cycle and a test email would be
generated to RCL Philippines to test for whether the content was in line with
the request by the requesting Royal Caribbean entity;
(d) Thereafter, RCL Philippines would send a sample of the output email to the
relevant Royal Caribbean entity to review; and
(e) The relevant Royal Caribbean entity would sign off on the implementation and
RCL Philippines would then implement the new process to go live.

7. Investigations revealed that the Data Breach Incident occurred because RCL
Philippines made an error in the coding of the email parameters in the Structured
Query Language (“SQL”) script when configuring the Hyperion System as
described in paragraph 6(b), leading to the Collated Payment Reminders being

sent to the first customers in the mailing lists instead of the Organisation.
Consequently, the personal data of the Singapore customers contained in the
Collated Payment Reminders were disclosed to certain unrelated customers.

8. Both the Organisation and RCL Philippines were not aware of this error until they
were informed of the Complaint to the Commission referenced in paragraph 1. As
the Automated Payment Reminder System was new and unfamiliar to the
Organisation at the material time, the Organisation and its employees were also
not aware that it was supposed to be receiving the Collated Payment Reminders.

9. The Data Breach Incident happened after the Organisation provided lists of
Singapore customers with outstanding payments due to RCL Philippines for
processing with the Hyperion System. The Commission is of the view that the
coding error that occurred during the configuration of the Hyperion System was
wholly within RCL Philippines’ operations and that the Data Breach Incident did not
arise from any business functions that the Organisation was conducting as a data
intermediary on behalf of RCL.

10. In the above circumstances, the Deputy Commissioner for Personal Data
Protection finds that the Organisation was not in breach of the Protection Obligation
under section 24 of the PDPA.

11. We note that the Organisation had taken the following remedial actions:
(a) Conducted additional trainings for its employees to be mindful of the
importance of data protection in its business processes;
(b) Reviewed its supervisory framework for new employees so that similar
incidents would not happen again; and
(c) Reviewed its communication with RCL Philippines for implementation of any
new processes.
The following is the provision of the Personal Data Protection Act 2012 cited in the above summary:
Protection of personal data
24. 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.

",Not in Breach,0d00bbb6002dda7ff71a02aa63df23ee41375297
36,36,1,952,Singtel was found not in breach of the PDPA in relation to an incident which occurred on or about 20 January 2021 whereby threat actor(s) exfiltrated personal data by exploiting zero-day vulnerabilities of a third party file transfer appliance.,"[""Protection"", ""Not in Breach"", ""Information and Communications""]",2022-05-19,https://www.pdpc.gov.sg/-/media/Files/PDPC/PDF-Files/Commissions-Decisions/Decision---Singapore-Telecommunication-Limited---101221.pdf,Protection,No Breach of the Protection Obligation by Singapore Telecommunications (Singtel),https://www.pdpc.gov.sg/all-commissions-decisions/2022/05/no-breach-of-the-protection-obligation-by-singapore-telecommunications,2022-05-19,"PERSONAL DATA PROTECTION COMMISSION

Case No. DP-2102-B7878

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

And

Singapore Telecommunication Limited

SUMMARY OF THE DECISION

1. On

February

2021,

Singapore

Telecommunication

Limited

(the

“Organisation”) notified the Personal Data Protection Commission (the
“Commission”) of a personal data breach that had occurred through the
exploitation of zero-day vulnerabilities in a File Transfer Appliance (“FTA”)
provided by a third party system (the “Incident”).

2. As a result of the Incident, 9,921 files containing personal data were exfiltrated.
The personal data of 163,370 individuals which included their name, NRIC
number, FIN, UIN, nationality, date of birth, address, email address, mobile
number, photograph, staff, company pass or ID, bank account number, credit
Page 1 of 3

card information (with expiry date), billing information, and vehicle number were
affected.

3. The Organisation engaged an external cybersecurity company, FireEye
Mandiant, to investigate the Incident. Its investigations found that the threat
actors had exploited two (2) zero-day vulnerabilities of the FTA to gain
unauthorised access to the FTA’s MySQL database and subsequent file
downloading.

4. Investigations revealed that the Organisation had a license to use the FTA with
the FTA developer, Accellion Pte Ltd (“Accellion”). Accellion was the only party
that had access to the proprietary source code to the FTA system. Accordingly,
the discovery and rectification of the zero-day vulnerabilities within the FTA
system fell within the sole responsibility and control of the developer. We are of
the view that the Organisation could not have detected or prevented the incident
as it had no control or visibility of the zero-day vulnerability of the FTA.

5. The Organisation had provided and made reasonable security arrangements to
protect personal data in its possession and/or control in relation to the Incident.
The Organisation maintained the practice of updating and patching the FTA
within five (5) days of patch/update receipt.

6. Following the Incident, the Organisation took prompt and extensive remedial
both to mitigate the effects of the Incident and enhance the robustness of its
security measures. This included shutting down the FTA, conducting thorough

Page 2 of 3

review of processes and file sharing protocols to enhance information security
posture, and offering identity monitoring service to the affected individuals.

7. In view of the above, the Deputy Commissioner for Personal Data Protection is
satisfied that the Organisation had met its Protection Obligation under section
24 of the PDPA and cannot be held liable for zero-day vulnerabilities on a third
party system. No enforcement action therefore needs to be taken in relation to
the Incident.

The following provision(s) of the Personal Data Protection Act 2012 had been cited in the
above summary:
Protection of personal data
24. An organisation shall protect personal data in its possession or under its control by
making reasonable security arrangements to prevent –
(a) unauthorised access, collection, use, disclosure, copying, modification, disposal or
similar risks; and
(b) the loss of any storage medium or device on which personal data is stored.

Page 3 of 3

",Not in Breach,572fbbe0157ad79a81e4ed46fce23091a479c4f6
37,37,1,952,Directions were issued to ACL Construction (S) for breach of the PDPA in relation to failure to appoint a data protection officer and no policies and practices in place to comply with the PDPA.,"[""Accountability"", ""Directions"", ""Construction"", ""No DPO""]",2022-04-21,https://www.pdpc.gov.sg/-/media/Files/PDPC/PDF-Files/Commissions-Decisions/Decision--ACL-Construction-S-Pte-Ltd--030222.pdf,Accountability,Breach of Accountability Obligation by ACL Construction (S),https://www.pdpc.gov.sg/all-commissions-decisions/2022/03/breach-of-accountability-obligation-by-acl-construction,2022-04-21,"PERSONAL DATA PROTECTION COMMISSION
Case No. DP-2107-B8598
In the matter of an investigation under section 50(1) of the
Personal Data Protection Act 2012
And
ACL Construction (S) Pte Ltd

SUMMARY OF THE DECISION

1. On 2 June 2021, the Personal Data Protection Commission (the “Commission”)
was notified that data from ACL Construction (S) Pte Ltd (the “Organisation”), a
company that provides pre-fabricated structures, structural steel products and
construction services, was being offered for sale on the darkweb by one
“Prometheus” (the “Incident”).

2. Investigations revealed that a few days ago, three ACL staff - a designer and two
sales executives had experienced difficulties when they tried to log in to access
their files. Thereafter, the ACL staff discovered that the files had been encrypted.
The Organisation then sought external IT support.

3. The Organisation informed the Commission that the affected files contained the
following data related to their projects:
(i) Quotation folder – quotations (to clients and from suppliers), delivery orders,
invoices and other supporting documents;
(ii) Common folder – project document and photographs; and
Page 1 of 3

(iii) Drawing folder – CAD drawings.

4. Our investigations revealed that the affected files contained the names of the
Organisation’s customers, the relevant liaison person, their business contact
number(s) and/or business email(s). As the names, business contact numbers and
business emails were not provided by the individuals concerned for a personal
purpose, they would constitute “business contact information” as defined under the
Personal Data Protection Act (“PDPA”), and fall outside the scope of the Act by
virtue of section 4(5) of the PDPA. Accordingly, while the Organisation may have
suffered a data breach, no personal data was in fact affected.

5. This finding alone would have brought the matter to a close. However, in the course
of our investigations, the Commission found out that the Organisation had failed to
designate one or more individuals, commonly known as a Data Protection Officer
(“DPO”), to be responsible for ensuring that the Organisation complies with the
PDPA, as required under section 11(3) of the PDPA. The Organisation’s omission
to have any data protection policies in place meant that it was also in breach of
section 12(a) of the PDPA.
6. The Commission is cognizant that by virtue of the nature of the Organisation’s
business, the Organisation primarily deals with business contact information from
its corporate clients. Having said that, while no personal data may have been
affected as a result of the Incident, the Organisation still has to comply with the
accountability obligation, as set out in sections 11 and 12 of the PDPA so as to
protect the personal data of its employees, and any other personal data it may
incidentally process, come into control or possession of.
Page 2 of 3

7. The Commission notes that after the Incident, the Organisation took prompt
remedial actions and duly appointed a member of its staff to be responsible for
ensuring that the Organisation complies with the PDPA.

8. Nonetheless, bearing in mind the Organisation’s low level of awareness of its
obligations under the PDPA, the Commission considered that it would be most
appropriate in lieu of imposing a financial penalty, to direct the Organisation to
comply with the following:
a. To develop and implement policies and practices to comply with the provisions
of the PDPA; and
b. Put in place a programme of compulsory training for employees of ACL on
compliance with the PDPA when handling personal data.

The following is the provision of the Personal Data Protection Act 2012 cited in the
above summary:
Compliance with PDPA
11(3). An organisation must designate one or more individuals to be responsible for ensuring that the
organisation complies with the PDPA.
Policies and practices
12(a). An Organisation must develop and implement policies and practices that are necessary for the
organisation to meet the obligations of the organisation under the PDPA.

Page 3 of 3

",Directions,e5d93d363b4513ab709353939decc81ce04eb8a1
38,38,1,952,"A financial penalty of $35,000 was imposed on GeniusU for failing to put in place reasonable security arrangements to prevent the unauthorised access and exfiltration of individuals' personal data stored in its staging database.","[""Protection"", ""Financial Penalty"", ""Education""]",2022-04-21,https://www.pdpc.gov.sg/-/media/Files/PDPC/PDF-Files/Commissions-Decisions/Decision---GeniusU-Pte-Ltd--180122.pdf,Protection,Breach of the Protection Obligation by GeniusU,https://www.pdpc.gov.sg/all-commissions-decisions/2022/03/breach-of-the-protection-obligation-by-geniusu,2022-04-21,"PERSONAL DATA PROTECTION COMMISSION
Case No. DP-2101-B7725
In the matter of an investigation under section 50(1) of the
Personal Data Protection Act 2012
And
GeniusU Pte. Ltd.

SUMMARY OF THE DECISION

On 12 January 2021, GeniusU Pte. Ltd. (the “Organisation”) notified the
Personal Data Protection Commission (the “Commission”) of unauthorized
access and exfiltration of a staging application database (the “Database”)
holding personal data (the “Incident”).

The personal data of approximately 1.26 million users were affected. The
datasets affected comprised first and last name, email address, location and last
sign-in IP address.

The Organisation’s internal investigations revealed that the likely cause of the
Incident was compromise of one of its developer’s password, either because the
developer used a weak password for his GitHub account or the password for his
GitHub account had been compromised. This allowed the threat actor to enter

the Organisation’s GitHub environment. As the Organisation had stored the login
credentials to the Database in the codebase in its GitHub environment, the threat
actor was able to gain access to and exfiltrate personal data stored in the
Database.

The Organisation took the following remedial measures after the Incident:
a.

Rotated the credentials of the Database;

Removed all hard-coded credentials from the codebase;

Purged all existing website sessions;

Removed all personal data from non-production environment servers,

Implemented multi-factor authentication on all work-related accounts;

Implemented a standardised cyber security policy and related procedures
for all staff; and

Notified users and the GDPR data authority (Ireland) of the Incident.

The Commission accepted the Organisation’s request for this matter to be
handled under the Commission’s expedited breach decision procedure. This
meant that the Organisation had voluntarily provided and unequivocally admitted

to the facts set out in this decision. The Organisation also admitted that it was in
breach of section 24 of the Personal Data Protection Act (the “PDPA”).

Based on its admissions, the Organisation had breached the Protection
Obligation by:

Storing credentials for the Database in the codebase in its GitHub
environment. This meant that once the threat actor was able to access
the GitHub environment, he was able to discover the credentials to
access personal data stored in the Database; and

Storing actual personal data in the Database that was in a nonproduction (testing) environment, which are usually not as secure as
production environments. Actual personal data should not be stored in
testing environments, which are known to be less secure.

In the circumstances, the Organisation is found to be in breach of section 24 of
the PDPA.

Having considered the circumstances set out above and the factors listed at
section 48J(6) of the PDPA and the circumstances of the case, including (i) the
Organisation’s upfront voluntary admission of liability which significantly reduced

the time and resources required for investigations; and (ii) the prompt remedial
actions undertaken by the Organisation, the Organisation is given a notice to pay
a financial penalty of $35,000.
9.

The Organisation must make payment of the financial penalty within 30 days
from the notice accompanying date this decision, 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.

10. In view of the remedial actions taken by the Organisation, the Commission will
not issue any directions under section 48I of the PDPA.

The following is the provision of the Personal Data Protection Act 2012 cited in the above summary:
Protection of personal data
24. An organisation shall protect personal data in its possession or under its control by making
reasonable security arrangements to prevent –
(a) unauthorised access, collection, use, disclosure, copying, modification, disposal or similar risks;
and
(b) the loss of any storage medium or device on which personal data is stored.

",Financial Penalty,7a86d2d632c8b7dd6e2f8666a6255cf824652a01
39,39,1,952,"A financial penalty of $20,000 was imposed on Trinity Christian Centre for failing to put in place reasonable security arrangements to prevent the unauthorised access of individuals' personal data hosted in its database servers.","[""Protection"", ""Financial Penalty"", ""Arts, Entertainment and Recreation"", ""Ransomware"", ""Remote Desktop Protocol""]",2022-04-21,https://www.pdpc.gov.sg/-/media/Files/PDPC/PDF-Files/Commissions-Decisions/Decision---Trinity-Christian-Centre-Limited---03022022.pdf,Protection,Breach of the Protection Obligation by Trinity Christian Centre,https://www.pdpc.gov.sg/all-commissions-decisions/2022/03/breach-of-the-protection-obligation-by-trinity-christian-centre,2022-04-21,"PERSONAL DATA PROTECTION COMMISSION

Case No. DP-2009-B7057

In the matter of an investigation under section 50(1) of the
Personal Data Protection Act 2012
And
Trinity Christian Centre Limited

SUMMARY OF THE DECISION

1. On 11 March 2021, Trinity Christian Centre Limited (the “Organisation”) notified
the Personal Data Protection Commission (the “Commission”) that its database
servers containing personal data were infected with ransomware on or around 17
February 2021 (the “Incident”).

2. The Organisation subsequently requested for this matter to be handled under the
Commission’s expedited breach decision procedure. In this regard, the
Organisation voluntarily provided and unequivocally admitted to the facts set out in
this decision. It also admitted that it was in breach of section 24 of the Personal
Data Protection Act (the “PDPA”).

The Incident
3. The Organisation runs Trinity Christian Church in Singapore.

4. At the time of the Incident, the database servers contained 72,285 individuals’ data.
The types of data affected for each individual varied, and included at times an
individual’s name, full identification number, residential address, contact number,
email address, photograph, date of birth, age, marital status, education level,
and/or description of medical condition (if applicable).

5. Investigations by the Organisation revealed that the Organisation maintained an
open and publicly exposed remote desktop protocol port. This allowed a threat
actor with access to compromised administrator account credentials to enter the
Organisation’s network and database servers to execute ransomware attack on 17
February 2021, rendering the databases inaccessible.

6. The Organisation managed to restore the affected databases from its back-up
copies. Based on the Organisation’s investigations, there was no evidence to
suggest that the threat actor exfiltrated the Organisation’s databases.

The Organisation’s Admission
7. The Organisation admitted that it had breached the Protection Obligation under
section 24 of the PDPA as:
2

a. It could have implemented separate access controls (i.e. separate logins) to
protect the databases containing personal data; and

b. The initial unauthorised entry to the Organisation’s network was through an
administrator account that the Organisation had assigned to an IT vendor it had
engaged to develop and test applications. The Organisation conceded that it
failed to stipulate data protection requirements on its vendor.

Remediation
8. Following the Incident, the Organisation notified its church members on 8 April
2021. The Organisation changed all user and administrator passwords, closed all
unused and open ports used for remote access and restricted logon access with
domain administrator privileges to servers and workstations. A security review was
also conducted and the Organisation implemented real time threat monitoring,
detection, and response measures.

The Commission’s Decision
9. As noted earlier, the Organisation admitted that it was in breach of section 24 of
the PDPA as it could have implemented separate access controls to protect the
databases containing personal data. In our view, the number and type of personal
data sets in the possession or under the control of the Organisation created a
3

security need for stronger access control beyond reliance on frontend password
protection. Indeed, with increasingly sophisticated phishing and social engineering
techniques, adding another layer of protection to protect backend database
servers, and manage the risks that frontend login credentials may be compromised
was a reasonable security measure, which the Organisation also accepted.

10. The Commission had also previously emphasised in our decisions1 and in the
Commission’s Guide to Managing Data Intermediaries that organisations that
engage IT vendors should ensure that their IT vendors are aware of the need for
personal data protection by making it part of their contractual terms.

11. The Organisation admitted that its contract with its IT vendor only contained a
general confidentiality clause not to disclose information obtained without the
Organisation’s prior written consent. Even though the Organisation was well aware
that its IT vendor would process personal data, the Organisation failed to stipulate
within the contract any requirements on the vendor to protect the church members’
personal data, thereby breaching section 24 of the PDPA.

12. In determining the directions to be imposed on the Organisation for the breach, the
Commissioner took into account the following factors:

See examples – Jigyasa [2020] SGPDPC 9, MDIS Corporation Pte Ltd [2020] SGPDPC 11 and Civil Service Club [2020]
SGPDPC 15.

Aggravating
(a) The high number of affected individuals of 72,285 which included
approximately 8,300 minors;
(b) The nature of the affected data. In particular, the affected databases
contained descriptions of medical conditions provided by individuals
counselling services and overseas mission applications. Individuals would
expect a high level of confidence when they convey such information to the
Organisation for handling;

Mitigating
(c) The Organisation’s upfront admission of breach of the Protection Obligation,
and the prompt remedial actions to mitigate the effects and prevent
recurrence of the Incident; and
(d) There was no evidence of exfiltration of the Organisation’s databases.

13. On account of the above, the Organisation is directed to pay a financial penalty of
$20,000 within 30 days from the date of this direction. In view of the remedial action
of the Organisation, the Commission will not be issuing any other directions.

The following provision of the Personal Data Protection Act 2012 had been cited in the
above summary:
Protection of personal data
24. An organisation shall protect personal data in its possession or under its control
by making reasonable security arrangements to prevent –
(a) unauthorised access, collection, use, disclosure, copying, modification, disposal
or similar risks; and
(b) the loss of any storage medium or device on which personal data is stored.

",Financial Penalty,1b58e6ca07c13ad8238e25acd672c8231540a608
40,40,1,952,"A financial penalty of $21,000 was imposed on Neo Yong Xiang for using his customers' personal data to register for prepaid SIM cards without their consent. The SIM cards were subsequently sold to anonymous individual(s) who used them to send specified messages in contravention of the Do Not Call provisions of the PDPA.","[""Consent"", ""Financial Penalty"", ""Others""]",2022-03-10,https://www.pdpc.gov.sg/-/media/Files/PDPC/PDF-Files/Commissions-Decisions/Decision---Neo-Yong-Xiang---29102021.pdf,Consent,Breach of the Consent and Purpose Limitation Obligations by Neo Yong Xiang trading as Yoshi Mobile,https://www.pdpc.gov.sg/all-commissions-decisions/2022/03/breach-of-the-consent-and-purpose-limitation-obligations-by-neo-yong-xiang-trading-as-yoshi-mobile,2022-03-10,"PERSONAL DATA PROTECTION COMMISSION

[2021] SGPDPC 12

Case No. DP-2013-B8088

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

Neo Yong Xiang (trading as Yoshi Mobile)

… Organisation

DECISION

Neo Yong Xiang (trading as Yoshi Mobile)

Lew Chuen Hong, Commissioner — Case No. DP-2013-B8088

29 October 2021

Introduction
1.

When customers purchased pre-paid SIM cards from a mobile phone shop at

Geylang Road, they would not have anticipated that their personal data would be
misused to register additional SIM cards for illegal sale. Unfortunately, this was exactly
what happened to at least 78 individuals who purchased pre-paid M1 SIM cards from
one Mr Neo Yong Xiang (“NYX”) the sole proprietor of Yoshi Mobile (“YM”).

The Commission observed that between January 2020 and November 2020,

there were 3,636 Do Not Call (“DNC”) complaints from persons who received specified
messages even though their telephone numbers are registered with the DNC register1.
Further analysis revealed that 1,379 of the messages were sent from 98 SIM cards
registered at YM. The Commission initiated investigations against NYX (trading as
YM) for suspected breaches of the Personal Data Protection Act 2012 (“PDPA”).

Facts of the Case
3.

NYX has operated YM since 2013. As an exclusive retailer of M1 SIM cards,

NYX was provided a terminal device installed at YM’s premises for the purposes of

Under Section 43 of the PDPA, a person is not allowed to send specified messages to a Singapore
telephone number registered with the DNC register unless the person has, at the time where he sends
the specified message, valid confirmation that the Singapore telephone number is not listed in the DNC
register.

SIM card registration (the “M1 Terminal Device”). SIM card registration had to be
carried out in accordance with the conditions of M1’s telecommunications licence
granted under Section 5 of the Telecommunications Act (Chapter 323). The typical
SIM card registration process in YM would be as follows:

(a)

First, the customer’s identity document (e.g. identity card, passport, work pass
etc.) would be scanned using the M1 Terminal Device. The system would
capture the customer’s personal data, and state whether the customer had
reached the permitted limit of 3 prepaid SIM cards.

(b)

Next, the barcode of the SIM card(s) would be scanned so that they could be
tagged to the registered customer.

(c)

Finally, a mobile application would be used to load credit value to the prepaid
SIM card(s) to activate them for usage. M1’s policy was for each prepaid M1
SIM card to have a zero-initial balance, and for retailers to load some or all of
the money paid by the customer.

The Commission’s investigations revealed that NYX exploited the above

registration process in order to use his customers’ personal data without consent to
register for additional prepaid M1 SIM cards that his customers did not intend to
purchase. NYX would do so by one of two methods:

(a)

Method 1 – After scanning a customer’s identity documents via the M1
Terminal Device, NYX would check whether the customer was still entitled to
purchase more SIM cards (in addition to the SIM card(s) that were intended to
be purchased). If so, NYX would proceed to register additional SIM card(s) to
the same customer without their knowledge (the “illicit SIM card(s)”).

(b)

Method 2 – Occasionally, customers who had completed the registration
process would not want to continue with their purchase after learning that the
credit value of the SIM card would have to be separately loaded. At this
juncture, instead of cancelling or reversing the registration process, NYX would
keep the SIM card(s) and activate them without the customer’s knowledge.

During investigations, NYX admitted that his purpose for registering the illicit

SIM cards was to sell them to earn extra money. In his three years of selling such illicit
SIM cards to anonymous walk-in customers, NYX estimated that he earned
approximately $15,000 (i.e. around 100 illicit SIM cards per year at a price of $50 per
card).

The affected personal data collected and used by NYX to register the illicit SIM

cards include, at a minimum, the following personal data of 78 individuals (used to
register 94 SIM cards):
(a)

the customers’ names;

(b)

the customers’ addresses; and

(c)

the customers’ NRIC numbers and/or work permit numbers.

After registering the illicit SIM cards, NYX would sell them to anonymous buyers

who occasionally patronised YM from 2018 to 2020. Investigations revealed that illicit
SIM cards registered at YM were exploited by unknown perpetrators to send
unsolicited spam and/or scam messages, often also in contravention of the DNC
provisions of the PDPA.

Findings and Basis for Determination

Section 2(1) of the PDPA defines an “organisation” broadly to include “any

individual, company, association or body of persons, corporate or unincorporated”. YM
is a sole proprietorship and has no separate legal personality from NYX. Accordingly,
NYX constitutes an organisation under the PDPA Further, NYX is bound by the
provisions of the PDPA (including Part IV) as he was acting in a business capacity in
selling the SIM cards to make a profit, and not a domestic capacity. As stated in Re
Sharon Assya Qadriyah Tang [2018] SGPDPC 1:
“9

…Although the PDPA defines “organisation” broadly to include

individuals, an individual is expressly excluded from the Data Protection
Provisions in the PDPA if the individual was acting in a personal or domestic
capacity. Therefore, when it comes to the application of the PDPA to
individuals, it is usually germane to the issue to determine whether the
individual was acting in a personal or domestic capacity. If the individual was
not acting in a personal or domestic capacity, then she will be treated as an
“organisation” for the purposes of the PDPA, and obliged to comply with the
Data Protection Provisions.

On the facts, the Respondent was clearly not acting in a personal or

domestic capacity in respect of the buying and selling of leads. The purchase
and sales of the leads were not for her own personal use or purposes, but in
order to make a profit. Under the PDPA, “business” includes an activity of any
organisation, whether or not carried on for purposes of gain, or conducted on a
regular, repetitive or continuous basis, but does not include an individual acting
in his personal or domestic capacity. In this regard, the converse of a person
acting in a personal or domestic capacity is one that acts in a business capacity.

This was the case for the Respondent in respect of the purchase and sale of
leads.”
[emphasis added]

Based on the circumstances set out above, the issues to be determined in this

case are:

(a)

Whether NYX breached the Consent Obligation under section 13 of the PDPA;
and

(b)

Whether NYX breached the Purpose Limitation Obligation under section 18 of
the PDPA.

The Consent Obligation under section 13 of the PDPA

10.

Under Section 13 of the PDPA, organisations are prohibited from collecting,

using or disclosing an individual’s personal data unless the individual gives, or is
deemed to have given, his consent, an exception to the requirement for consent
applies, or if otherwise authorised under the PDPA or any other written law (the
“Consent Obligation”). In this connection, Section 14(1) of the PDPA further provides
that an individual has not given consent unless he has been notified of the purposes
for which his personal data was being collected, used or disclosed. If an organisation
fails to do so, any consent obtained from an individual is invalid.

11.

On the facts of this case, NYX breached the Consent Obligation by using his

customers’ personal data to register the illicit SIM cards for sale to anonymous buyers.
When NYX used Method 1, NYX’s customer(s) only consented to the collection and

use of their personal data for the purpose of registering the number of SIM cards which
they had requested. They did not provide consent to NYX to use their personal data
for any other purpose, including the registration of additional SIM cards.

12.

In the case of Method 2, the customers withdrew their consent to the collection

and use of their personal data to purchase M1 SIM cards, and NYX should have
cancelled the SIM card registrations. Instead, he went behind his customers’ backs
and used their personal data without consent to register illicit SIM cards.

13.

In the premises, NYX is determined to have breached the Consent Obligation

by using his customers’ personal data without their consent.

The Purpose Limitation Obligation under Section 18 of the PDPA

14.

Under Section 18 of the PDPA, an organisation may collect, use or disclose

personal data about an individual only for purposes that a reasonable person would
consider appropriate in the circumstances, and where that individual has been
informed of the said purposes under Section 20 of the PDPA (the “Purpose Limitation
Obligation”). As set out in the Commission’s Advisory Guidelines on Key Concepts in
the PDPA2:
“The main objective of the Purpose Limitation Obligation is to ensure that
organisations collect, use and disclose personal data that are relevant for the
purposes, and only for purposes that are reasonable. Consistent with the
Notification Obligation, the Purpose Limitation Obligation also limits the
purposes for which personal data may be collected, used or disclosed to those

Advisory Guidelines on Key Concepts in the PDPA (Rev 1 February 2021)

which have been informed to the individuals concerned pursuant to the
Notification Obligation (where applicable).

For the purposes of section 18 (and as stated in that section), whether a
purpose is reasonable depends on whether a reasonable person would
consider

it appropriate

the

circumstances.

Hence

the

particular

circumstances involved need to be taken into account in determining whether
the purpose of such collection, use or disclosure is reasonable. For example, a
purpose that is in violation of a law or which would be harmful to the individual
concerned is unlikely to be considered appropriate by a reasonable person.”
[emphasis added]

15.

The Purpose Limitation Obligation operates independently from the Consent

Obligation. Even if the data subject gave his consent for his personal data to be used
for a particular purpose, it does not follow that the said purpose is reasonable in the
circumstances. As stated in Re AIA Singapore Pte Ltd [2016] SGPDPC 10 at [18]:
“Section 18 of the PDPA provides, inter alia, that an organisation may collect,
use or disclose personal data about an individual only for purposes that a
reasonable person would consider appropriate in the circumstances. It should
be borne in mind that Section 18 of the PDPA is an independent obligation that
organisations would need to comply with even if it had obtained the consent
from the relevant individual for the collection, use or disclosure of his or her
personal data. This is an important aspect of the PDPA as it is effective in
addressing excesses in the collection, use or disclosure of personal data under
a broadly-worded consent clause, like in the present case.”

[emphasis added]

16.

In this case, NYX has admitted that he had fraudulently used his customers’

personal data for the purpose of registering illicit SIM cards in order to sell them to
anonymous buyers. This is plainly not a reasonable purpose under any circumstances,
as individuals could not have reasonably intended for their personal data to be used
to register illicit SIM cards purely for NYX’s financial gain.

17.

In the premises, NYX is determined to have breached the Purpose Limitation

Obligation.
The Commissioner’s Decision

18.

In determining whether NYX should be required to pay a financial penalty under

section 48J of the PDPA, the factors listed at section 48J(6) of the PDPA were
considered, with particular emphasis on the following aggravating and mitigating
factors:

Aggravating Factors
(a)

NYX’s breaches of the PDPA were difficult to detect as it included a high

degree of planning and pre-meditation by him to evade detection by authorities;
(b)

NYX was entrusted by his customers with their personal data for the

purpose of registering prepaid SIM cards, and he abused their trust by misusing
their personal data;
(c)

NYX’s breaches of the PDPA caused inconvenience to innocent parties,

as the illicit SIM cards sold by him were used to send unsolicited messages to
phone numbers that were registered with the DNC register;

(d)

Through the sale of the illicit SIM cards for approximately 3 years, NYX

financially gained at least $15,000 for his misuse of his customers’ personal
data; and

Mitigating Factor
(e)

NYX admitted to liability early in the investigation process, thus reducing

the time and resources expended on investigations.

NYX’s representations
19.

On 7 September 2021, NYX was notified of the Commissioner’s Preliminary

Decision (as set out above) and intention to impose a financial penalty of $35,000. On
20 September 2021, NYX submitted written representations on the amount of financial
penalty that was to be imposed. NYX raised the following factors to argue for either a
waiver of the imposition of a financial penalty, or (in the alternative) for a lower financial
penalty:

(a)

NYX was facing a difficult financial situation, as he had low savings / monthly
income, and was responsible for servicing several outstanding liabilities (such
as a vehicle loan, housing loan and renovation loan). Additionally, he was also
responsible for paying the medical bills of his parent. NYX claimed that it would
cause him undue hardship if a high financial penalty was imposed.

(b)

NYX had breached the PDPA for financial gain due to extenuating
circumstances, as his business was adversely affected by COVID-19 and the

landlord of Yoshi Mobile had refused to pass on the relevant COVID-19 rental
relief provided by the Government.

(c)

NYX’s breaches of the PDPA can be distinguished from the breaches
committed by other organisations on the basis that he did not leak or sell the
personal data for financial gain. Instead, he had merely used his customers’
personal data to register for SIM cards and was not the person who used the
illicit SIM cards to send unsolicited text messages to telephone numbers on the
DNC register. In this connection, NYX pointed to other decisions where the
Commission had imposed a lower financial penalty or a warning on other
organisations that had breached the PDPA.

20.

After careful consideration, we have accepted and taken into account NYX’s

representation at [19(a)] above, but are unable to do the same with respect to the
representations set out in [19(b)] and [19(c)] above.

21.

When imposing financial penalties, the Commission may consider the personal

and financial circumstances of the organisation / individual, bearing in mind that
financial penalties imposed should avoid imposing a crushing burden or cause undue
hardship on organisations: see Re Jigyasa [2021] SGPDPCR 1. In considering NYX’s
representations at [19(a)], the Commission gave due consideration to the existing
financial commitments on NYX and accepted that the imposition of a heavy financial
penalty would cause substantial hardship to NYX.

22.

We are unable to accept NYX’s representation at [19(b)] that he had breached

the PDPA due to extenuating financial difficulties that arose due to the COVID-19

pandemic. Based on the Commission’s investigations, NYX has been using his
customers’ personal data to register illicit SIM cards for the purpose of selling them to
third parties since 2018. NYX’s modus operandi (as described in [4]) predated the
onset of COVID-19, and it is disingenuous for NYX to attribute his actions to the
financial difficulties that followed the COVID-19 pandemic.

23.

We are also unable to accept NYX’s representation at [19(c)] that his breach of

the PDPA was less serious than the breaches committed by various other
organisations. Compared with the decisions that NYX mentioned, NYX’s culpability is
more egregious as his breach involved the intentional misuse of personal data from a
position of trust, over a protracted period of time, for personal financial gain. While
NYX did not send any unsolicited text messages or made any unsolicited calls directly
to telephone numbers on the DNC register, his sale of the unsolicited SIM cards to
anonymous buyers (that NYX did not verify or identify) facilitated the commission of
those offences and the harm caused as a consequence. The anonymous sale of illicit
SIM cards may also be the catalyst or precursor for other illicit activities.

24.

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

the representations made by NYX, the Commissioner has decided to reduce the
financial penalty to $21,000. This decision is made on an exceptional basis, and
should not be taken as setting any precedent for future cases. The Commissioner
hereby requires NYX to pay a financial penalty of $21,000 in 18 monthly instalments
by the due dates as set out in the notice accompanying this decision, 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.

25.

The Commission will not be issuing any further directions given that M1 has

barred NYX from offering the sale of its prepaid SIM cards.

YEONG ZEE KIN
DEPUTY COMMISSIONER
FOR COMMISSIONER FOR PERSONAL DATA PROTECTION

",Financial Penalty,9701ccc45e49e35f3e4018e10b92d445aca1c569
41,41,1,952,"A financial penalty of $4,000 was imposed on Tanah Merah Country Club for failing to put in place reasonable security to protect personal data in its possession. The incident resulted in personal data being accessed.","[""Protection"", ""Financial Penalty"", ""Arts, Entertainment and Recreation"", ""Email"", ""Password policy""]",2022-02-18,https://www.pdpc.gov.sg/-/media/Files/PDPC/PDF-Files/Commissions-Decisions/Decision---Tanah-Merah-Country-Club---20122021.pdf,Protection,Breach of the Protection Obligation by Tanah Merah Country Club,https://www.pdpc.gov.sg/all-commissions-decisions/2022/02/breach-of-the-protection-by-tanah-merah-country-club,2022-02-18,"PERSONAL DATA PROTECTION COMMISSION
Case No. DP-2102-B7951
In the matter of an investigation under section 50(1) of the
Personal Data Protection Act 2012
And
Tanah Merah Country Club

SUMMARY OF THE DECISION

1. On 24 February 2021, Tanah Merah Country Club (the “Organisation”) notified
the Personal Data Protection Commission (the “Commission”) that an
employee’s (the “Employee”) email account had been compromised and 600
phishing emails had been sent to various individuals on 22 February 2021 (the
“Incident”).

2. The Organisation subsequently requested for this matter to be handled under the
Commission’s expedited breach decision procedure. This meant that the
Organisation voluntarily and unequivocally admitted to the facts set out within this
decision. It also admitted that it was in breach of section 24 of the Personal Data
Protection Act (the “PDPA”).

3. The Organisation’s investigations revealed that it was likely that the Organisation’s
email accounts had been subjected to password spraying attacks. Password
spraying is a type of password attack where a threat actor uses a few commonly
used or default passwords against many different accounts. In contrast to

traditional brute-force attacks, where the targeted account may quickly get lockedout due to account-lockout policies that only allow for a limited number of failed
attempts, password spraying attacks allow a threat actor to mount an attack against
many accounts with a single commonly used password, while remaining
undetected, before attempting the second password. At the time of the Incident,
the Employee was using the password “TMCC@1234”, which the Employee had
not changed for a period of nearly 5 years, since 2016 to the time of the Incident
on 22 February 2021.

4. After gaining access to the Employee’s email account, the threat actor accessed
the personal data of 467 individuals, including:
a. The email addresses of 155 club members and 284 members of public,
which the threat actor had used to send phishing emails to.
b. The name, and/or NRIC number, and/or email addresses of a further 28
individuals contained within the emails.

5. Prior to the Incident, the Organisation had informed its employees via an email IT
newsletter in August 2018 of the need to change their password once every 3
months, and to use passwords which are at least 8 characters, with a combination
of uppercase letter, lowercase letter, special character, and number. In September
2019, the Organisation sent another email IT newsletter to inform its employees of
the implementation of a domain password policy. This meant that the abovementioned password requirements became system enforced.

6. Despite disseminating these email IT newsletters where it referred to its password
requirements and the implementation of a system-enforced domain password
policy, the Organisation failed to further develop its password requirements into a
full-fledged password policy in writing and disseminate it in such a manner whereby
all its employees, new and old, could easily take reference from the password
policy and consult the password policy at any time. It was only on 23 February
2021, after the Incident had occurred, that the Organisation documented its
password policy in writing.

7. We had previously emphasized the importance of organisations having a written
personal data protection policy so as to guide its employees and staff in Re
Furnituremart.sg [2017] SGPDPC 7. In that case, the Commission noted at [14] as
follows:
“The lack of a written policy is a big drawback to the protection of personal data.
Without having a policy in writing, employees and staff would not have a reference
for the organisation’s policies and practices which they are to follow in order to
protect personal data. Such policies and practices would be ineffective if passed
on by word of mouth, and indeed, the Organisation may run the risk of the policies
and practices being passed on incorrectly. Having a written policy is conducive to
the conduct of internal training, which is a necessary component of an internal data
protection programme”.

8. A properly documented password policy is therefore crucial for the protection of
personal data. In this regard, the Organisation admitted that it had breached the
Protection Obligation under section 24 of the PDPA as it failed to document its
password policy in writing.

9. The Commission recently issued a “Guide to Data Protection Practices for ICT
Systems” on 14 September 2021. In the Guide, we noted that in order to maintain
good governance over its personal data and mitigate data breach risks throughout
the data lifecycle, organisations should develop and implement ICT security
policies for data protection. Key ICT policies would include a password policy.

10. Prior to the issuance of this Guide, the Commission had also released a Handbook
on “How to Guard Against Common Types of Data Breaches”, which is
complemented by the Checklists to Guard Against Common Types of Data
Breaches. In the Handbook, the Commission identified poor management of
accounts and passwords as one of the five common causes and types of data
breaches. We noted that the use of default value, weak or easily guessable
passwords result in accounts being particularly vulnerable to brute force or
dictionary attacks. We therefore recommended that organisations adopt and
implement a strong password policy, with the following good practices:

(i)

Enforcing a password history policy to ensure that employees do not reuse
their previous passwords;

(ii)

Encouraging users to use passphrases such as “Iwant2l@se10kg”, which
may be long and complex, yet easy to remember; and

(iii)

Discouraging users from using the same passwords across different
systems.

11. In this regard, we observed that the Organisation’s email IT newsletters to its
employees had cited “TMCC_Password_123” as an example of what amounts to
a good password. Unfortunately, we are unable to endorse the Organisation’s

choice of “TMCC_Password_123” as an example of what amounts to a good
password. In Re Chizzle Pte Ltd [2020] SGPDPCR 1, the Commission highlighted
that a password that complies with the recommended password complexity rules
in form could still be a weak password easily guessable and vulnerable to
password attacks if the password incorporates components such as the
organisation’s name, which is not difficult to guess and crack. In this regard, we
note that in the Organisation’s password policy, which it adopted on 23 February
2021, the Organisation now recommends that its employees refrain from the use
of the Organisation’s name or abbreviations such as “TMCC”.

12. In addition, the Organisation also admitted that it had failed to provide structured
and organised training for its staff on how to ensure compliance with the obligations
under the PDPA and how personal data should be handled in the course of their
work. Only ad-hoc and informal training had been provided. As a result, the
Employee lacked the awareness of the need to change her password at more
regular intervals and of the need to use a strong password. The Employee did not
receive system prompts to change her password as the domain password policy
was not pushed down to her system due to a domain controller disruption.

13. The Commission wishes to emphasize that staff training is a critical and necessary
component to ensure that an organisation is well placed to protect the personal
data in its possession and/or control. The Protection Obligation under section 24
of the PDPA extends to and includes the training of all employees who have to
handle personal data in the course of their work so that an organisation’s
employees can then successfully adopt and implement the policies and best

practices necessary to ensure the protection of personal data in an organisation’s
possession and/or control.

14. In light of the above, the Deputy Commissioner for Personal Data Protection finds
the Organisation in breach of the Protection Obligation under section 24 of the
Personal Data Protection Act 2012 (the “PDPA”).

15. Following the incident, the Organisation engaged an IT forensic vendor for
investigation. We note that the Organisation has since implemented the measures
recommended by the vendor to improve its cybersecurity. The Organisation has
also documented its password policy, implemented regular updates, conducted
user awareness training, and other trainings on personal data protection.

16. The Organisation cooperated with the Commission’s investigations, admitted to its
breach of the Protection Obligation, and took prompt remedial actions.

17. Having considered the circumstances set out above, the factors listed at section
48J(6) of the PDPA, and in particular, the Organisation’s voluntary admission to
being in breach of section 24 of the PDPA under the Expedited Breach Decision
Procedure, which is a significant mitigation factor, the Deputy Commissioner for
Personal Data Protection requires the Organisation to pay a financial penalty of
$4,000 within 30 days from the notice accompanying date this decision, 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.

18. Finally, in view of the remedial actions taken by the Organisation, no other
directions are necessary.

The following is the provision of the Personal Data Protection Act 2012 cited in the above summary:
Protection of personal data
24. An organisation shall protect personal data in its possession or under its control by making
reasonable security arrangements to prevent –
(a) unauthorised access, collection, use, disclosure, copying, modification, disposal or similar risks;
and
(b) the loss of any storage medium or device on which personal data is stored.

",Financial Penalty,db3f5f6adf8ce0a020293ba554d69dc62a612298
42,42,1,952,"A financial penalty of $10,000 was imposed on North London Collegiate School (Singapore) for failing to put in place reasonable security arrangements to prevent the unauthorised access of its student applicants’ personal data residing in a website directory folder.","[""Protection"", ""Financial Penalty"", ""Education""]",2022-02-18,https://www.pdpc.gov.sg/-/media/Files/PDPC/PDF-Files/Commissions-Decisions/Decision---NLCS---01122021.pdf,Protection,Breach of the Protection Obligation by North London Collegiate School (Singapore),https://www.pdpc.gov.sg/all-commissions-decisions/2022/02/breach-of-the-protection-obligation-by-north-london-collegiate-school,2022-02-18,"PERSONAL DATA PROTECTION COMMISSION
Case No. DP-2107-B8562
In the matter of an investigation under section 50(1) of the
Personal Data Protection Act 2012
And
North London Collegiate School (Singapore) Pte. Ltd.

SUMMARY OF THE DECISION

On 2 July 2021, North London Collegiate School (Singapore) Pte. Ltd. (the
“Organisation”) notified the Personal Data Protection Commission (the
“Commission”) that a parent of a student was able to view and access a student
report by the Organisation by performing searches using internet search engines.
(the “Incident”).

The Organisation subsequently requested for this matter to be handled under the
Commission’s expedited breach decision procedure. In this regard, the
Organisation voluntarily provided and unequivocally admitted to the facts set out
in this decision. It also admitted that it was in breach of section 24 of the Personal
Data Protection Act (the “PDPA”).

Investigations revealed that, from December 2019 to July 2021, parents of
prospective students could submit documents for admission applications via the
Organisation’s website (https://nlcssingapore.sg/).

All submitted documents

were stored in a directory/ folder of the website. However, the website directory/

folder was not adequately secured from automatic indexing by web crawlers. As
a result, the submitted documents were indexed by search engines and could
show up in online search results.

The table below summarises1 the number of affected individuals for each type of
document accessible in the directory/ folder (the “Compromised Documents”):
S/N

Type of Document

Number

(Scanned or Electronic Copies)

Affected

Passport

1,742

Identity cards (i.e NRICs)

1,714

Digital Photographs of applicants

720

Birth Certificates

709

Academic Reports

676

Immunization Records

670

Individuals

The documents above contained the following types of personal data (the
“Personal Data Sets”) at risk of unauthorised access in the Incident - Name,
Address, NRIC number, Passport Number, Photograph, Date of Birth,
immunization details and academic details.

The Organisation admitted that it had only relied on a Robots.txt file deployed on
its Website to instruct search engines to refrain from indexing the documents in
the website directory folder. However, it is well established that the robots
exclusion protocol is not mandatory, in the sense that it relies on compliance of

This table sets out the documents at risk of unauthorised access in the Incident. Not all of these types of
documents were affected for each Affected Individual, and the documents affected for each Affected Individual
varies. A unique Affected Individual could have multiple type of documents affected.

web crawlers without an enforcement mechanism. Therefore, Organisations
storing personal data in website directory/ folders should instead implement
proper folder or directory permissions and access controls to prevent unintended
access by web crawlers.

In addition, the Organisation had stated that it relied on a related group company
to setup and manage its website, including to make the necessary security
arrangements to protect any personal data collected. However, in this case, there
were no clear business requirements (e.g. contractual stipulations) specifying
that the Organisation was relying on the sister company to recommend and/or
implement security arrangements to protect personal data that resides in the
website directory/ folder.

Re Everlast Projects Pte Ltd & Others [2020] SGPDPC 20 stated the
arrangements to be made when organisations in a group used IT services
provided by a group member. An organisation receiving IT services from another
organisation of the group should ensure that the latter is bound by either written
agreements or group rules to protect personal data in the course of provision of
the services. Absent clear written personal data protection requirements of the
group member managing the Organisation’s website, the responsibility to make
reasonable security arrangements to protect the Affected Personal Data in the
directory/ folder of the website remained squarely with the Organisation.

10. Following the incident, the Organisation ceased the collection of documents via
its website and would now be utilizing a specialized school admission software
to manage the application process and the personal data submitted. Additionally,
the Organisation would be implementing appropriate binding corporate rules to
govern the centralization of corporate functions and the handling of data
protection and cybersecurity within its corporate group.

11. The Organisation cooperated with the Commission’s investigations, admitted to
its breach of the Protection Obligation and took prompt remedial actions to
address its inadequacies in its processes. There were also no indications that
that the personal data affected in the Incident had been misused in any form.
However, personal data of minors were at risk of unauthorised access.

12. Having considered the circumstances set out above and the factors listed at
section 48J(6) of the PDPA, the Deputy Commissioner for Personal Data
Protection requires the Organisation to pay a financial penalty of $10,000 within
30 days from the notice accompanying date this decision, 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.

13. In view of the remedial actions taken by the Organisation, no other directions are
necessary.

The following is the provision of the Personal Data Protection Act 2012 cited in the above summary:
Protection of personal data
24. An organisation shall protect personal data in its possession or under its control by making
reasonable security arrangements to prevent –
(a) unauthorised access, collection, use, disclosure, copying, modification, disposal or similar risks;
and
(b) the loss of any storage medium or device on which personal data is stored.

",Financial Penalty,2b442c9cd53b17e7887a8bb1bdfc113eeb21ae47
43,43,1,952,"A financial penalty of $14,000 was imposed on Nature Society (Singapore) for breaches of the PDPA. First, the organisation failed to put in place reasonable measures to protect personal data on its website database. Second, it did not appoint a data protection officer. Lastly, it did not have written policies and practices necessary to comply with the PDPA.","[""Protection"", ""Accountability"", ""Financial Penalty"", ""Others""]",2022-01-14,https://www.pdpc.gov.sg/-/media/Files/PDPC/PDF-Files/Commissions-Decisions/Summary-Decision---NSS---03122021.pdf,"Protection, Accountability",Breach of the Protection and Accountability Obligations by Nature Society (Singapore),https://www.pdpc.gov.sg/all-commissions-decisions/2021/12/breach-of-the-protection-and-accountability-obligations-by-nature-society,2022-01-14,"PERSONAL DATA PROTECTION COMMISSION
Case No. DP-2011-B7351
In the matter of an investigation under section 50(1) of the
Personal Data Protection Act 2012
And
Nature Society (Singapore)

SUMMARY OF THE DECISION

1. On 6 November 2020, the Personal Data Protection Commission (the
“Commission”) received information of an online article reporting about hacked
databases being made available for downloads on several hacking forums and
Telegram channels. In the article, Nature Society (Singapore) (the ""Organisation"")
was named as one of the affected Organisations (the “Incident”).

2. The personal data of 5,131 members and non-members who had created
membership and user accounts on the Organisation’s website were affected in the
Incident. The datasets affected comprised of names, usernames, passwords
(encrypted), email addresses, telephone numbers, types of membership, gender,
mailing addresses, dates of births, occupation, company and nationality.

3. Following the Incident, the Organisation engaged two IT professionals to carry out
an investigation and analysis of the Organisation's website. The investigation and
analysis revealed vulnerabilities in the Organisation's website and suspicious SQL
injection activities prior to the Incident. The possible attack vector was identified as
a SQL injection attack which led to personal data on the Organisation's website
database being accessed and exfiltrated by unknown parties.

4. The Organisation took the following remedial measures after the Incident:
(a)

Edited the website to stop all online membership sign-ups/renewals and
logins to the website;

(b)

Removed all members' and users' data from the website database;

(c)

Backed up the website database and kept all personal data offline;

(d)

Change all login passwords;

(e)

Notified all affected individuals of the Incident via email;

(f)

Appointed a Data Protection Officer (""DPO"")

(g)

Developed and implemented a personal data policy; and

(d)

Engaging vendors to develop a new website to improve security.

5. In its representations to the Commission, the Organisation admitted to having
breached the Accountability Obligation under sections 11(3) and 12(a) and the
Protection Obligation under section 24 of the Personal Data Protection Act 2012
(""PDPA""), and requested for the matter to be dealt with in accordance with the
Commission’s Expedited Decision Procedure.
2

Breach of Section 11(3) of the PDPA
6. First, the Organisation admitted it did not designate one or more individuals
(typically referred to as a DPO) to be responsible for ensuring that the Organisation
complies with the PDPA. The responsibilities of a DPO includes (a) ensuring
compliance with the PDPA, (b) fostering a data protection culture, (c) handling and
managing personal data queries and complaints, (d) alerting management to any
risks with regard to personal data and (e) liaising with the Commission if necessary.
From the foregoing, it is clear that the DPO plays a vital role in implementing and
building a robust data protection framework to ensure an organisation’s compliance
with its obligations under the PDPA.

Breach of Section 12(a) of the PDPA
7. Second, the Organisation admitted it did not develop and implement any personal
data protection policy prior to the Incident. In this regard, it is important to reiterate
that at the very basic level, an overarching personal data protection policy has to
be developed and implemented to ensure a consistent minimum data protection
standard across an organisation's practices, procedures and activities.

Breach of Section 24 of the PDPA

8. Third, the Organisation admitted that it did not make reasonable security
arrangements to protect the personal data on its website database. After the
Organisation's website was designed and developed by an external vendor in
2011, the Organisation did not have any contract/retainer agreement with the
external vendor to maintain the website's security. As a result, the responsibility of
protecting its website fell squarely on the Organisation. However, the Organisation
failed to carry out any security measures e.g. conducting necessary security
updates, patches and penetration tests, thus leaving its website vulnerable to
attacks.

9. In the circumstances, the Organisation is found to have breached sections 11(3),
12(a) and 24 of the PDPA.

Commission’s Decision
10. After considering the factors listed at section 48J(6) of the PDPA and the
circumstances of this case, including (i) the Organisation's upfront voluntary
admission of liability which significantly reduced the time and resources required
for investigations; (ii) the fact that the Organisation is a non-profit, registered
society and (iii) the Organisation's prompt remedial actions, the Organisation is
given notice to pay a financial penalty of $14,000.

11. The Organisation must make payment of the financial penalty within 30 days from

the date of the notice accompanying this decision, 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.

12. In view of the remedial actions taken by the Organisation, the Commission will not
issue any directions under section 48I of the PDPA.

The following are the provision of the Personal Data Protection Act 2012 cited in the above summary:
Compliance with Act
11(3). An organisation shall designate one or more individuals to be responsible for ensuring that the
organisation complies with this Act.
Policies and practices
12(a). An organisation shall develop and implement practices that are necessary for the organisation
to meet the obligations of the organisation under this Act.
Protection of personal data
24. An organisation must protect personal data in its possession or under its control by making
reasonable security arrangements to prevent –
(a) unauthorised access, collection, use, disclosure, copying, modification or disposal or similar risks
and;
(b) the loss of any storage medium or device on which personal data is stored.

",Financial Penalty,50aef1ea4a6b3252366a112e13092602d7c8bd3b
44,44,1,952,A warning was issued to Belden Singapore for a breach of the PDPA in relation to the transfer of its Singapore-based employees’ personal data to its parent company in the United States.,"[""Transfer Limitation"", ""Warning"", ""Manufacturing""]",2021-12-09,https://www.pdpc.gov.sg/-/media/Files/PDPC/PDF-Files/Commissions-Decisions/Decision---Belden-Singapore-Private-Limited---12112021.pdf,Transfer Limitation,Breach of the Transfer Limitation Obligation by Belden Singapore,https://www.pdpc.gov.sg/all-commissions-decisions/2021/12/breach-of-the-transfer-limitation-obligation-by-belden-singapore,2021-12-09,"PERSONAL DATA PROTECTION COMMISSION

[2021] SGPDPC 13

Case No. DP-2011-B7423, DP-2011-B7433

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

And

(1) Belden Singapore Private Limited

(2) Grass Valley Singapore Pte Ltd
… Organisations

DECISION

Belden Singapore Private Limited & Anor
[2021] SGPDPC 13

Yeong Zee Kin, Deputy Commissioner — Case No. DP-2011-B7423, DP-2011B7433

12 November 2021
Introduction
1.

It is not unusual for a corporate group with a multi-national footprint to conduct

cross-border transfers of personal data between its various entities. However, such
arrangements also mean that data transferred from an organisation based in
Singapore might risk exposure to data breach incidents in another jurisdiction. This is
one such incident.

On 19 November 2020 and 20 November 2020, Belden Singapore Private

Limited (“Belden Singapore”) and Grass Valley Singapore Pte Ltd (“GVSPL”)
(collectively, the “Organisations”) notified the Personal Data Protection Commission
(the “Commission”) of a data breach incident whereby an unauthorised third party
had gained access to business servers of the Belden Group, and managed to exfiltrate
information, including personal data of the employees of the Organisations
(“Incident”).

Facts of the Case
3.

The Belden Group is a group of companies involved in the manufacturing of

networking, connectivity and cable products. Its various subsidiaries and affiliated
companies operate in the Americas, Europe, Middle East, Africa and the Asia Pacific
region (the “Belden entities”). The overall parent entity, Belden Incorporated
(“Belden Inc.”) is headquartered in St Louis, Missouri, United States. Belden
Singapore is part of the Belden Group.

As the main Human Resources (“HR”) functions of Belden Singapore are

conducted by Belden Inc., Belden Singapore transfers the personal data of its
employees to Belden Inc., which are then stored in Belden Inc.’s servers. The terms
on which the various Belden entities transfer and process personal data are governed
by the Global Data Transfer Agreement dated 1 September 2020 (“GDTA”).

GVSPL is part of a group of companies (the “Grass Valley entities”) that were

formerly part of the global Belden Group. In July 2020, the Grass Valley entities
(including GVSPL) were acquired by another company. Under the terms of the
acquisition, Belden Inc. agreed to provide transition services, including administration
of its information technology and HR systems for a period of time after the acquisition.
Therefore, the personal data of GVSPL’s employees (and the employees of other
Grass Valley entities) were transferred to Belden Inc. and stored in Belden Inc.’s
servers. GVSPL’s parent company, Grass Valley USA, LLC (“GV USA”) (on behalf of
its subsidiaries and affiliates, including GVSPL) and Belden Inc. entered into a Data
3

Sharing Agreement dated 18 June 2020 (“DSA”) to govern the sharing of data
(including personal data) between the parties.

On 12 November 2020, the Belden Group’s information technology team

noticed anomalies in its systems. Subsequent investigations revealed that, from
September to November 2020, a threat actor had accessed the Belden Group’s
servers in the USA and other jurisdictions through the use of malicious software at
various times and exfiltrated the information and data contained therein. The
compromise of GVSPL’s Personal Data Sets is taken to have arisen from the
unauthorised access to the Belden Group’s servers since there was no evidence of
any unauthorised access directly into the systems of the Grass Valley entities.

The personal data of 126 individuals related to Belden Singapore (current and

former employees as well as non-employees such as suppliers / vendors) and 63
individuals related to GVSPL (current and former employees) were exfiltrated in the
Incident (collectively, the “Personal Data Sets”). The types of personal data exfiltrated
included the following:
(a)

Name;

(b)

Address;

(c)

Email Address;

(d)

Telephone Number;

(e)

Date of Birth;

(f)

Identification Number;

(g)

Marital Status;
4

(h)

Photographs;

(i)

Salary Information; and

(j)

Individual Tax Information.

Upon discovery of the Incident, Belden Inc. implemented, or has been in the

process of implementing, the following remediation actions:

(a)

The following security measures:
i.

Conducted an audit of system administrator accounts to confirm that it
was for valid users only

(b)

ii.

Reviewed and developed plan to address incident closure activities

iii.

Improved relevancy and frequency of security awareness campaign.

The following short-term and long-term containment actions:
i.

Roll out an endpoint security software to all server and client systems

ii.

Block command and control IP addresses on perimeter firewalls

iii.

Update existing security software definitions

iv.

Block access to Mega (cloud storage file hosting service) on firewalls

Disallow syncing of data from internal systems to unapproved external
cloud storage services

vi.

Remove unnecessary accounts from privileged security groups

vii.

Rebuild compromised systems

viii.

Reboot business-critical systems that cannot be rebuilt

ix.

Expedite patching of critical and high severity vulnerabilities
5

Reset passwords for Domains and Enterprise administrators

xi.

Reset passwords for all other privileged users

xii.

Reset the password for the Kerberos account

xiii.

Perform enterprise-wide password reset

xiv.

Ensured no direct remote access is available on the systems exposed
to the Internet

Findings and Basis for Determination
9.

As a preliminary point, Belden Inc. is responsible for maintaining the security

and integrity of the Belden Group’s systems (including its servers) and implementing
the appropriate safeguards. However, the data protection obligations in the Personal
Data Protection Act 2012 (“PDPA”) does not apply to Belden Inc., as it does not
process personal data in Singapore. It is further noted that Belden Inc. has made
reports to the relevant authorities in the jurisdictions where the compromised servers
are located in. Therefore, no findings are made against Belden Inc.

The Transfer Limitation Obligation under section 26 of the PDPA

10.

Section 26(1) of the PDPA provides that an organisation shall not transfer any

requirements are prescribed in Part III of the Personal Data Protection Regulations
2014 (“PDPR”)1 . In particular:

(a)

Regulation 9(1)(b) of the PDPR requires an organisation that transfers personal
data to a country or territory outside of Singapore to take appropriate steps to
ensure that the recipient of personal data is bound by legally enforceable
obligations (in accordance with Regulation 10) to provide to the transferred
personal data a standard of protection that is at least comparable to that under
the PDPA;

(b)

Regulation 10(1)(b) of the PDPR provides for contracts to be one such legally
enforceable obligation. Regulation 10(2) in turn provides that such contract
must require the recipient of the transferred personal data to provide a
comparable standard of protection , and must specify the countries and
territories to which the personal data may be transferred under the contract;
and

(c)

Regulation 10(1)(c) of the PDPR provides binding corporate rules to be another
such legally enforceable obligations. Regulation 10(3) in turn provides that such
binding corporate rules require every recipient to provide a comparable
standard of protection , and must specify (i) the recipients of the transferred
personal data to which the binding corporate rules apply; (ii) the countries and

As the Incident occurred on or around September 2020, the Personal Data Protection Regulations 2014 apply.
However, from 1 February 2021 onwards, the Personal Data Protection Regulations 2021 would apply.

territories to which the personal data may be transferred under the binding
corporate rules; and (iii) the rights and obligations provided by the binding
corporate rules. Further, such binding corporate rules may only be used by
recipients that are related to the transferring organisation.

11.

To comply with the Transfer Limitation Obligation in the context of an intra-

group transfer where there is centralisation of corporate functions, group members
involved in ongoing relationships for regular cross-border transfers of personal data
out of Singapore are required to take reasonable steps to ascertain that the overseas
transferee has implemented the appropriate policies, practices and / or technical
measures to ensure that the transferred personal data is provided with the requisite
level of protection. This is no different from an organisation’s obligation to carry out
the necessary due diligence vis-à-vis the transfer of personal data to an overseas data
intermediary, since the overseas transferee is a data intermediary even though they
are members within the same group of companies. As stated in the Commission’s
Advisory Guidelines on Key Concepts in the PDPA2:
“Overseas transfers of personal data
6.22

Advisory Guidelines on Key Concepts in the PDPA (Rev 1 February 2021)
8

intermediary or transferred overseas by the data intermediary in
Singapore as part of its processing on behalf and for the purposes of the
organisation.

6.23

The Transfer Limitation Obligation requires that an organisation ensures
that personal data transferred overseas is protected to a standard
comparable with the Data Protection Provisions. The onus is on the
transferring organisation to undertake appropriate due diligence and
obtain assurances when engaging a data intermediary to ensure that it
is capable of doing so. In undertaking its due diligence, transferring
organisations may rely on data intermediaries’ extant protection policies
and practices, including their assurances of compliance with relevant
industry standards or certification.”

Whether Belden Singapore complied with the Transfer Limitation Obligation

12.

It is determined that Belden Singapore had not complied with the Transfer

Limitation Obligation for the reasons explained below.

13.

At the material time, Belden Inc. and certain other Belden entities had put in

place a binding intra-group contract called the Global Data Transfer Agreement dated
1 September 2020 (“GDTA”), which governs the terms on which the various Belden
entities transfer personal data to each other.

14.

The GDTA contained provisions that required Belden Inc. to provide any

personal data transferred from Singapore a comparable standard of protection to that
under the PDPA at the time of the Incident. In particular:

(a)

Clause 5.2.2 provided that “Where Belden Data and/or Client Data originating
in a Non-EEA territory (including in the United Kingdom, if at any time the United
Kingdom is not in the EEA or beyond any transition period) (the Originating
Territory”) are Processed in a territory which is different from the Originating
Territory (the “Importing Territory”), then the Data Importer will Process such
Belden Data and/or Client Data to a standard consistent with the Applicable
Privacy Law(s) of the Originating Territory…”

(b)

Clause 19.5.5 of Schedule 5 required the data importer (i.e. Belden Inc.) to
ensure that any transfer of personal data to a country or territory outside
Singapore is provided a standard of protection that is comparable to the
protection under the PDPA.

15.

In addition to the above, the GDTA also contained provisions that require the

transferee (the “Data Importer”) to implement measures aimed at addressing identified
security risks to the personal data transferred and assisting the transferor (the “Data
Exporter”) to comply with the relevant data protection laws. In particular:

(a)

Clause 4.1(c)(ii) required the Data Importer to “comply with any requirements
arising under any Applicable Privacy Law(s) to protect the Belden and/or Client
Data it received including, but not limited to the following:
10

(A)

assistance, taking into account the nature of the Processing, by
appropriate technical and organisation measures, insofar as this is
possible, to fulfil any obligations the Data Exporter may have to respond
to requests from data subjects to exercise their rights under Applicable
Privacy Law(s) assistance;

(B)

assisting the Data Exporter as necessary to comply with its obligations
under Applicable Privacy Law(s) including (without limitation) to conduct
a data protection impact assessment and/or to consult with a
Supervisory Authority, in each case taking into account the nature of the
Processing and the information available to the Data Importer; and

(C)

not knowingly performing its obligations under this Agreement in such a
way as to cause the Data Exporter to breach any of its obligations under
Applicable Privacy Law(s);

(D)

ensuring the reliability of any persons it authorises to access the Belden
and/or Client Data (including employees, agents and sub-Processors)
and ensure that they have undergone appropriate training in the care,
protection and handling of Belden and/or Client Data;

(E)

it will ensure that any persons authorised to process the Belden and/or
Client Data have committed themselves to confidentiality or are under
an appropriate statutory obligation of confidentiality;

(F)

it will maintain appropriate and sufficient technical and organisational
security measures to protect such Belden and/or Client Data against a

Security Breach. Such measures will include as a minimum the Belden
Security Measures; and
(G)

it will permit the Data Exporter such access to its premises, computer
and other information systems, records, document and agreements as
the Data Exporter may reasonably require to satisfy itself that the Data
Importer is complying with its obligations under the Agreement; and

(H)

it will, at the choice of the Data Exporter, delete or return all Belden
and/or Client Data to the Data Exporter after the end of the provision or
services relating to processing, unless EU law or any EU Member State
law requires storage of the Client Data.”

(b)

Clause 6 also required the Data Importer to carry out certain measures in the
event of a security breach to investigate the breach, mitigate its effects and
assist the Data Exporter to fulfill any obligations under the Applicable Privacy
Law(s).

16.

In this connection, the Belden Group has put in place the following policies and

measures concerning the treatment of personal data:

(a)

Data Handling Standard – Governs the handling of electronic and physical
data throughout the Belden Group;

(b)

Personal Data Handling Standard – Governs the handling of all forms of
personal data throughout the Belden Group;

(c)

Data Classification Policy – Sets the standards for protection of information
assets from accidental or unlawful destruction, loss, unauthorised access,
modification, compromise, disclosure or other misuse; and

(d)

Record Creation, Retention, Retrieval and Disposal Policy – Establishes
requirements for creating, retaining, retrieving and disposing of records within
the Belden Group.

17.

Despite the suite of policies and technical measures adopted by the Belden

Group, the GDTA and the above policies did not enable Belden Singapore to meet the
requirements in Regulation 9(1)(b), read with Regulations 10(1)(b) and 10(2) when the
Incident occurred:

(a)

The GDTA was not legally binding on Belden Singapore at the material time as
Belden Singapore had not acceded to the GDTA. For Belden Singapore to be
bound by the GDTA, it must have executed a Deed of Accension under Clause
12.1. However, at the time of the Incident, Belden Singapore had not executed
such a Deed of Ascension.

(b)

Since the Belden Group opted to structure its data governance architecture
around an intra-group contract (i.e. the GDTA), it is trite that the principle of
privity of contracts applies, and only the parties to a contract are able to enforce
the rights and obligations arising therein. Although the GDTA did, at the time of
the Incident, require Belden Inc. to comply with the applicable standards under
the PDPA while importing / processing personal data from Singapore (Clause
13

19.5.5 of Schedule 5), such obligations were not legally enforceable by Belden
Singapore. Absent such a mechanism, Belden Singapore had no legal means
to ascertain and ensure that the data transferred outside Singapore was
afforded the same level of protection as under the PDPA.

(c)

Belden Singapore has acknowledged that this was a lapse. It subsequently
rectified this oversight by signing a Deed of Accession on 18 June 2021.

(d)

Nevertheless, the investigations revealed that, in practice, all the relevant
Belden group policies, practices and technical measures mentioned in
paragraphs 14 to 16 were implemented in full to ensure that personal data
transferred from Singapore are afforded a level of protection comparable to that
provided under the PDPA. Therefore, Belden Singapore’s breach constituted a
lapse in legal formalities rather than a failure to comply with the substance of
the Transfer Limitation Obligation.

Whether GVSPL complied with the Transfer Limitation Obligation

18.

GVSPL was determined to have complied with the Transfer Limitation

Obligation for the reasons explained below.

19.

At the material time, GVSPL (as a subsidiary of GV USA) and Belden Inc. was

bound by a Data Sharing Agreement dated 18 June 2020 (“DSA”), which governed
the terms on which GVSPL transferred personal data to Belden Inc. The DSA is in
compliance with Regulation 9(1)(b), read with Regulations 10(1)(b) and 10(2) of the
14

PDPR. Clause 10.1 of the DSA provided that, in the case of international transfers of
data (including personal data):
“The Receiving Party shall not process any Data (not permit any Data to be
processed) in a territory outside of the European Economic Area (“EEA”) unless
it has taken such measures as are necessary to ensure the transfer is in
compliance with Applicable Data Protection Law3. Such measures may include
(without limitation); (a) transferring the Data to a recipient in a country that the
European Commission has decided provides adequate protection for personal
data; (b) to a recipient that has achieved binding corporate rules authorisation
in accordance with Applicable Data Protection Law; (c) to a recipient in the
United States that maintains a valid and up-to-date EU-US Privacy Shield
certification or (d) to a recipient that has executed standard contractual clauses
adopted or approved by the European Commission or by virtue of entering into
this Agreement.”

20.

Whilst Clause 10.1 of the DSA does not mention the PDPA specifically, it does

require a Grass Valley entity (including GVSPL) to take measures as are necessary
to ensure the transfer is in compliance with the Applicable Data Protection Law, which
– in the context of GVSPL – is the PDPA.

Defined to mean “all worldwide data protection and privacy laws and regulations applicable to the personal
data in question, including, where applicable, EU Data Protection Law.”
3

21.

Additionally, the DSA also contains several provisions aimed at addressing

identifiable security risks posed to the transferred personal data as well as ensuring
that the Receiving Party assists the Disclosing Party. In particular:

(a)

Clause 6.1(c) required the Receiving Party to assist the Disclosing Party as
necessary to comply with its obligations under the Applicable Data Protection
Law (defined to mean all worldwide data protection and privacy laws and
regulations application to the personal data in question) including (but not
limited to) conducting any data protection impact assessments, consultation
with a supervisory authority and fulfilment of any obligations the Disclosing
Party may have to respond to requests from data subjects to exercise their
rights under the Applicable Data Protection Law;

(b)

Clause 6.1(d) required the Receiving Party to ensure that any persons
authorised to process the personal data to have committed themselves to
confidentiality or are under an appropriate statutory obligation of confidentiality;
and

(c)

Clause 7.1 provided that the Receiving Party “shall maintain appropriate and
sufficient technical and organisational security measures to protect the Data
against a Security Incident, taking into account state of the art, the costs of
implementation and the nature, scope, context and purposes of processing, as
well as the risks of varying likelihood and severity for the rights and freedoms
of the data subject(s)”. Clause 7.2 further stipulates certain actions that the
16

Receiving Party is required to take in the event of a confirmed Security Incident
to mitigate the effects of the incident and assist the Disclosing Party to fulfill any
obligations under the Applicable Data Protection Law.

22.

Finally, the group policies and measures concerning the treatment of personal

data enumerated in paragraph 16 also applied to the transfers from GVSPL within the
Belden Group.
The Deputy Commissioner’s Decision

23.

In light of Belden Singapore’s breach of the Transfer Limitation Obligation, the

Commission is empowered under section 48I of the PDPA to issue Belden Singapore
such directions as it deems fit to ensure compliance with the PDPA. This may include
directing Belden Singapore to pay a financial penalty of such amount not exceeding
$1 million as the Commission thinks fit.

24.

In considering whether a direction should be given to Belden Singapore in this

case, it is noted that:

(a)

It was an oversight that Belden Singapore did not sign a Deed of Accession
prior to the Incident, and this lapse has been rectified by the signing of the Deed
of Ascension.

(b)

Belden Singapore’s breach of the Transfer Limitation obligation was technical,
and a failure of legal formalities that was not substantive in nature. As stated in
paragraph 17(d), at the operational level, the suite of Belden group policies,
17

practices and technical measures implemented were sufficient to ensure that
personal data transferred from Singapore to Belden Inc. were afforded a level
of protection comparable to that provided under the PDPA.

25.

Having considered all of the above circumstances, Belden Singapore is

administered a warning in respect of its breach of the Transfer Limitation Obligation.
No other directions are necessary in view of the remedial actions already taken,
namely, Belden Singapore’s accession to the GDTA.

YEONG ZEE KIN
DEPUTY COMMISSIONER
FOR PERSONAL DATA PROTECTION

",Warning,a89e11d9b22ce2cc69d737938faf4e47ad9addbb
45,45,1,952,Giordano was found not in breach of the PDPA in relation to an unauthorised network entry and ransomware infection that affected two of its systems storing personal data.,"[""Protection"", ""Not in Breach"", ""Wholesale and Retail Trade"", ""Ransomware"", ""Phishing""]",2021-11-11,https://www.pdpc.gov.sg/-/media/Files/PDPC/PDF-Files/Commissions-Decisions/Decision--Giordano-Originals-S-Pte-Ltd--151021.pdf,Protection,No Breach of the Protection Obligation by Giordano,https://www.pdpc.gov.sg/all-commissions-decisions/2021/11/no-breach-of-the-protection-obligation-by-giordano,2021-11-11,"PERSONAL DATA PROTECTION COMMISSION
Case No. DP-2011-B7387

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

Giordano Originals (s) Pte Ltd

SUMMARY OF THE DECISION

1. On 3 December 2020, the Personal Data Protection Commission (the
“Commission”) was notified by Giordano Originals (S) Pte Ltd (the
“Organisation”) of an unauthorized network entry and ransomware infection at
the OS and server level that occurred on or about 12 July 2020 (the “Incident”).
2. As a result of the Incident, two of the Organisation’s systems, one which stores
the personal data of its employees and second, the personal data of its
members were affected.
3. The Organisation’s own and independent investigation conducted found no
sign of suspicious activity in the Singapore network, and no impact beyond the
Singapore network. The unauthorised entry had most likely occurred through
the use of compromised credentials obtained through phishing.

4. Personal data of 790,000 members and 184 employees in encrypted form were
affected. The personal data of members comprised names (20% of the
members), contact number and partial date of birth (without birth year). The
personal data of employees comprised name, NRIC, address, gender, age,
contact number, email address, educational and salary information.

5. Investigations revealed that the Organisation had in place reasonable security
measures that are consistent with the recommendations that the Personal Data
Protection Commission had made in our recent Handbook on “How to Guard
Against Common Types of Data Breaches” on how to prevent malware or
phishing attacks. The Organisation had installed and deployed various endpoint
security solutions, which was complemented with real-time system monitoring
for any Internet traffic abnormalities. Even before the Incident, the Organisation
also conducted regular periodic system maintenance, reviews and updates
(such as vulnerability scanning and patching).

6. More importantly, the Organisation had also ensured that its data was regularly
and automatically backed-up, which was a key recommendation that the
Commission made in our Handbook.

7. In addition, the Organisation had also taken steps to better protect the personal
data affected by encrypting the personal data using current industry-standard
RSA algorithm and passphrase. As a result, the personal data affected by the
ransomware was not legible without decryption.

8. The Commission endorses the proper use of industry-standard encryption to
protect personal data, and will give due weight to Organisations which have
implemented the recommendations we made in our Handbook in determining
whether an organisation has complied with its Protection Obligation under
section 24 of the Personal Data Protection Act 2012 (the “PDPA”), or as a
strong mitigation factor in the event of the Commission finds that there has been
a breach of section 24 of the PDPA.

9. Following the Incident, the Organisation took prompt and extensive remedial
both to mitigate the effects of the Incident and enhance the robustness of its
security measures. This included increased frequency of staff phishing
simulation trainings and security reviews as well as additional monitoring
measures. There was no evidence of exfiltration of the personal data or
decryption of the personal data. The Organisation was also able to fully restore
the personal data from its backups.

10. In light of the reasons discussed above, the Deputy Commissioner for Personal
Data Protection is satisfied that the Organisation had met its Protection
Obligation under section 24 of the PDPA. In light of our findings, we will not be
issuing any directions or taking any further enforcement action against the
Organisation in relation to the Incident.

",Not in Breach,3967d62cd80927b7c190ce8deba0812d8d97eeb5
46,46,1,952,"A financial penalty of $74,000 was imposed on Commeasure for failing to put in place reasonable security arrangements to prevent the unauthorised access and exfiltration of customers’ personal data hosted in a cloud database.","[""Protection"", ""Financial Penalty"", ""Accommodation and F&B""]",2021-11-11,https://www.pdpc.gov.sg/-/media/Files/PDPC/PDF-Files/Commissions-Decisions/Decision---Commeasure-Pte-Ltd---15092021.pdf,Protection,Breach of the Protection Obligation by Commeasure,https://www.pdpc.gov.sg/all-commissions-decisions/2021/11/breach-of-the-protection-obligation-by-commeasure,2021-11-11,"PERSONAL DATA PROTECTION COMMISSION

[2021] SGPDPC 11

Case No. DP-2009-B7057

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

And

Commeasure Pte Ltd

… Organisation

DECISION

Commeasure Pte Ltd.
[2021] SGPDPC 11

Lew Chuen Hong, Commissioner — Case No. DP-2009-B7057
15 September 2021

Introduction
1

On 25 September 2020, the Personal Data Protection Commission (“the Commission”)

received a data breach notification from Commeasure Pte Ltd (“the Organisation”) that its
database containing 5,892,843 customer records had been accessed and exfiltrated (“the
Incident”). The Organisation first found out about the data breach on 19 September 2020 when
a cybersecurity company based in Atlanta, United States of America, approached the
Organisation with an offer to contain the breach and retrieve the data from the hackers. The
Commission commenced investigations into the Incident thereafter.
Facts of the Case
Background
2

The Organisation was incorporated in Singapore in 2014, and operates a hotel booking

platform www.reddoorz.com which serves customers in the Southeast Asian region, such as
Indonesia, Singapore, Philippines, Vietnam and Thailand. The Singapore office is primarily
engaged in sales, finance and administrative activities, while all IT functions (including the
management of the affected application package in this case) were managed by the
Organisation’s subsidiary company, Commeasure Solutions India Pvt Ltd (“CPL India”).
Cause of the Incident
3

Investigations revealed that the unknown threat actor(s) had most likely gained access

and exfiltrated the Organisation’s database of customer records hosted in an Amazon RDS
cloud database, after they obtained an Amazon Web Services (“AWS”) access key. The AWS
2

access key was embedded within an Android application package (“the affected APK”)
publicly available for download from the Google Play Store.
4

This affected APK was created sometime in 2015, when the Organisation was still a

start-up, and was last updated in January 2018. Even though the AWS access key had access
to a “live” or production database, the AWS access key was embedded in the APK, and
erroneously marked as a “test” key by the then-developers. With the exception of one of the
Organisation’s co-founders and Chief Technology Officer, all the developers have since left
the Organisation. Most unfortunately, even though the Organisation regarded this APK as
“defunct”, the APK remained publicly available for download on the Google Play Store until
the Organisation became aware of the Incident and removed the affected APK.
5

The fact that the Organisation had treated the affected APK as a “defunct” APK meant

that even though the Organisation had engaged a cybersecurity company to conduct a security
review and penetration testing sometime from September 2019 to December 2019, it was not
within the scope of the security review or penetration tests. Consequently, the vulnerability was
left undetected and exposed until the Organisation found out about the Incident. Likewise, even
though the Organisation used “Proguard” on its current Android apps to prevent reverse
engineering of APKs, which may have prevented the unknown threat actors from retrieving the
AWS access key, the Organisation failed to review and deploy “Proguard” on the affected APK
which it regarded as “defunct”.
6

As a result of the Incident, the Organisation’s database containing 5,892,843 customer

records which included the customer’s name, contact number, email address, date of birth, a
hashed password (encrypted with one-way BCrypt hash algorithm) used by the customer to
access their “RedDoorz” account and their booking information was accessed and exfiltrated
by unknown threat actor(s). Based on the Organisation’s investigations, the unknown threat
actor(s) did not gain access or download the customers’ masked credit card numbers.
Remedial actions
7

Following the Incident, the Organisation took the following remedial actions:
a.

CPL India immediately removed the affected APK from the Google Play Store;

The old access keys were invalidated and new access keys were created. The

infrastructure and code repository access credentials were changed;
c.

IP blocking of suspicious traffic was enabled; and

Informed all the affected customers via email on 26 September 2020 of the data

breach, advising them to change their RedDoorz account password as an added
precautionary measure, and to avoid using the same password on other digital
platforms.
8

To prevent a recurrence of the Incident or similar incidents, the Organisation also took

the following remedial actions:
a.

The Organisation amended its credential policy to clearly prohibit developers

from embedding access codes in any code base;
b.

The Organisation upgraded their IT infrastructure to a private space for isolation

of the customer database from the Internet. Only whitelisted IP addresses were allowed
connection to ‘live’ databases;
c.

The Organisation separated the accounts for production and staging

environments for all AWS services. Two-factor authentication was enabled for all tools
and accounts used by developers. VPN-based control was implemented to access
infrastructure resources;
d.

The Organisation configured alerts to capture mySQL dump query. Web

application firewalls were set up. An audit of all user access to the AWS environment
was conducted; and
e.

The Organisation appointed a cybersecurity company to conduct vulnerability

assessment and penetration testing of all its existing applications.
Findings and Basis for Determination
Whether the Organisation contravened the Protection Obligation

Section 24 of the Personal Data Protection Act 2012 (“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 “Protection Obligation”). For the reasons set out
below, the Organisation failed to implement reasonable security arrangements to protect the
personal data in its control.
10

The Organisation collected the personal data of customers when they created a

“RedDoorz” account through its hotel booking platform www.reddoorz.com. Even though the
Organisation’s customer database was hosted using Amazon RDS on cloud, on servers
physically located in North Virginia, United States of America, the database remained under
the Organisation’s control throughout as the Organisation could access, use and remove the
data.
11

In Re The Cellar Door Pte Ltd,1 we found that even though the organisation was not in

direct possession of the personal data that was held in the data intermediary’s servers, it was
still obliged to implement reasonable security arrangements to protect the personal data as it
had control over such data. Likewise, even though AWS was responsible for the security of the
cloud infrastructure that it provided to the Organisation, the Organisation bore ultimate
responsibility under section 24 of the PDPA for making reasonable security arrangements to
protect all the customers’ data under its control.
12

The data breach occurred because the Organisation embedded the AWS access key,

which allowed access to the “live” or production database, in the APK. The root cause was
therefore in the application, which was clearly within the Organisation’s responsibility. This
presented a clear security risk. The AWS access key comprises of two parts, first, the access
key ID, and second, the secret access key, and was effectively the Organisation’s username and
password. In a webpage titled “Best practices for managing AWS access keys”, AWS advised
users to protect the access keys as “anyone who has the access keys for your AWS account root
user has unrestricted access to all resources in your AWS account” 2. AWS also cautioned
users not to “embed access keys directly into code”, which was exactly what the Organisation

1 [2017] PDP Digest 160.
2 https://docs.aws.amazon.com (last accessed on 6 August 2021).

had done in the present case. We therefore find the Organisation in breach of section 24 of the
PDPA for reflecting the AWS access key in the affected APK.
13

In the course of investigations, the Organisation explained that its failure to implement

sufficiently robust processes to manage its inventory of infrastructure access keys was
attributable to the high turnover of its employees from the time of its inception to the discovery
of the Incident. This explanation is unacceptable, however sympathetic one might be to the
human resource issues that the Organisation had to manage. The Organisation’s responsibility
to protect personal data in its control or possession commences ought not to have been
subjected to staff movement or appointment.
14

In Re WTS Automotive Services Pte Ltd,3 we highlighted the importance of conducting

a “regular review to ensure that the website collecting personal data and the electronic database
storing the personal data has reasonable security arrangements to prevent unauthorised access,
collection, use, disclosure, copying, modification, disposal or similar risks” as the “personal
data of individuals may be exposed if the website or database in which it is stored contains
vulnerabilities”.4 The Commission reiterates that it is necessary for an organisation to
“[c]onduct regular ICT security audits, scans and tests to detect vulnerabilities”.5
15

In this case, the Organisation conducted internal security testing and application

architecture reviews every quarter and had engaged a cybersecurity company to conduct a
security review and penetration testing sometime from September 2019 to December 2019.
The Organisation admitted however, that it “overlooked” including the affected APK in the
security review as it was “old”. In addition, the Organisation admitted that the AWS access key
had been mistakenly marked as a “test key”. This resulted in its omission from the security
review as well as from the Organisation’s periodic review of accounts and login credentials.
16

It is important to highlight that the Organisation remained responsible for the affected

APK. The Organisation’s failure to include the affected APK and the AWS access key within
the scope of the security review arose because of the Organisation’s negligence to include them

3 [2019] PDP Digest 317.
4 Personal Data Protection Commission, Guide to Data Protection Impact Assessments (1 November 2017) at

para. 8.3.
5 Personal Data Protection Commission, Guide to Securing Personal Data in Electronic Medium (revised 20
January 2017) at para. 6.1.

in its inventory of IT assets in production after the Organisation had wrongly labelled the
affected APK as “defunct” and the AWS access key as a “test” key.
17

Accordingly, we are not satisfied that the IT security reviews that the Organisation

conducted were sufficiently rigorous, and met the standard required under section 24 of the
PDPA. We are therefore of the view that the Organisation has breached section 24 of the PDPA
for failing to include the affected APK and AWS access key in the Organisation’s security
reviews. If a security review had examined the affected APK or the AWS access key, the
vulnerability exposed by the embedded AWS access key would have been discovered, and the
Incident could have been prevented.
The Commission’s Directions
18

In determining whether to impose a financial penalty on the Organisation pursuant to

section 48J(1) of the PDPA, and if so, the amount of such financial penalty, we took into
account the factors listed at section 48(6) of the PDPA. The Commission notes that the data
breach affected 5,892,843 individuals whose personal data was exfiltrated. This is the largest
data breach that has occurred since the PDPA came into effect. Further, prior to the exfiltration
of the data in September 2020, the affected APK with the embedded AWS access key had
remained publicly available for download on the Google Play Store for a significant duration
of time. A lengthy period of 2 years and 9 months passed from the time the Organisation made
its last update to the affected APK in January 2018 to 19 September 2020, when the
Organisation finally found out about the data breach.
19

Having said that, the Commission also took into account the following mitigating

factors:
(a)

The Organisation was cooperative in the course of investigations and had

provided prompt responses to PDPC’s requests for information;
(b)

The Organisation implemented remedial actions to address the Incident; and

(c)

The Organisation had conducted periodic security reviews which promised to

offer some data protection, albeit their efforts were ultimately futile as these security
reviews did not include the affected APK.

In deciding the amount of financial penalty to be imposed, we also considered that the

Organisation, which operates in the hospitality industry, had been severely impacted by the
COVID-19 pandemic. Having considered all the relevant factors of this case, the
Commissioner hereby requires the Organisation to pay a financial penalty of $74,000 within
30 days from the date of the relevant notice accompanying this decision, 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 such financial penalty until the financial penalty is paid
in full.

YEONG ZEE KIN
DEPUTY COMMISSIONER
FOR COMMISSIONER FOR PERSONAL DATA PROTECTION

6 Cap 322, R5, 2014 Rev Ed.

",Financial Penalty,07efcafd13b2f83b14c9de466d3a142032ed8020
47,47,1,952,"A financial penalty of $10,000 was imposed on ChampionTutor for failing to put in place reasonable security arrangements to protect personal data in its possession. The incident resulted in the personal data being exposed.","[""Protection"", ""Financial Penalty"", ""Education""]",2021-10-14,https://www.pdpc.gov.sg/-/media/Files/PDPC/PDF-Files/Commissions-Decisions/Decision--ChampionTutor-Inc-Private-Limited--10082021.pdf,Protection,Breach of the Protection Obligation by ChampionTutor,https://www.pdpc.gov.sg/all-commissions-decisions/2021/10/breach-of-the-protection-obligation-by-championtutor,2021-10-14,"PERSONAL DATA PROTECTION COMMISSION
Case No. DP-2103-B7984

In the matter of an investigation under section 50(1) of the
Personal Data Protection Act 2012
And
ChampionTutor Inc. (Private Limited)

SUMMARY OF THE DECISION

1. On 24 February 2021, the Personal Data Protection Commission (the “Commission”)
received information that ChampionTutor Inc. (Private Limited)’s (the “Organisation”)
database, containing personal data of individuals, was being sold on dark web (the
“Incident”).

2. The Organisation was not aware of the Incident until it was notified by the Commission.
The cause of the Incident was suspected to be SQL injection of the Organisation’s website.
The Organisation knew about this SQL injection vulnerability when it conducted a
penetration test in December 2020. The Organisation had instructed its developer, based in
India, to fix the vulnerability. However, the developer did not act on the request and this
vulnerability was left unfixed until the Incident happened.

3. As a result, the personal data of 4,625 students were affected. The personal data included
name, email address, contact number and address.

4. The Organisation took the following remedial measures after the Incident:

a. Engaged a new team of developers to fix all the SQL injection vulnerabilities;

b. Parameterised SQL statements by disallowing data-directed context changes to prevent
SQL injection attacks from resurfacing; and

c. Is in the process of revamping the entire website source codes to reduce possible
vulnerabilities.

5. The Organisation admitted to having breached the Protection Obligation under section 24
of the Personal Data Protection Act (the “PDPA”), and requested for the matter to be dealt
with in accordance with the Commission’s Expedited Decision Procedure.

6. The Organisation admitted it was aware of the SQL injection vulnerability in December
2020. Yet, the Organisation failed to take active steps to fix the vulnerability even when its
developer was not responsive, purportedly due to the COVID-19 pandemic, and the
Organisation left the vulnerability unresolved until the Incident happened.

7. In the circumstances, the Organisation is found to have breached section 24 of the PDPA.

8. On 14 July 2021, the Organisation was notified of the Commission’s intention to impose a
financial penalty based on the Commission’s consideration of the factors listed under
section 48J(6) of the PDPA, and the circumstances of this case, in particular (i) the
Organisation’s upfront voluntary admission of liability which significantly reduced the
time and resources required for investigations; and (ii) the prompt remedial actions
undertaken by the Organisation. The Organisation was invited to make representations.

9. Having considered the Organisation’s representations dated 28 July 2021, the Deputy
Commissioner hereby directs the Organisation to pay a financial penalty of $10,000 in 12
instalments by the due dates as set out in the accompanying notice, failing which the full
outstanding amount shall become due and payable immediately and 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.

10. In view of the remedial actions taken by the Organisation, the Commission will not issue
any directions under section 48I of the PDPA.

",Financial Penalty,001064522a1c6277a0c24b9cf1a09495440cf2e8
48,48,1,952,A warning was issued to The National Kidney Foundation for failing to put in place reasonable security to protect the personal data in its possession. The incident resulted in personal data being downloaded.,"[""Protection"", ""Warning"", ""Healthcare"", ""Phishing"", ""Email""]",2021-10-14,https://www.pdpc.gov.sg/-/media/Files/PDPC/PDF-Files/Commissions-Decisions/Decision---The-National-Kidney-Foundation---15092021.pdf,Protection,Breach of the Protection Obligation by The National Kidney Foundation,https://www.pdpc.gov.sg/all-commissions-decisions/2021/10/breach-of-the-protection-obligation-by-the-national-kidney-foundation,2021-10-14,"PERSONAL DATA PROTECTION COMMISSION

[2021] SGPDPC 10

Case No DP-2005-B6353

In the matter of an investigation under section 50(1)
of the Personal Data Protection Act 2012
And
The National Kidney Foundation
… Organisation

DECISION

The National Kidney Foundation
[2021] SGPDPC 10
Yeong Zee Kin, Deputy Commissioner — Case No. DP-2005-B6353
15 September 2021

Introduction
1

On 22 May 2020, the Personal Data Protection Commission (the “Commission”)

received a data breach notification from the National Kidney Foundation (the “Organisation”).
The Organisation had discovered that on 17 May 2020, a hacker had gained access to the work
email account of one of its employees (“Employee A”) and had likely exfiltrated the personal
data contained in the email account (the “Incident”).
Background
2

The Organisation is a prominent non-profit health organisation in Singapore that

provides health services, including subsidised kidney dialysis. Employee A is an executive in
the Organisation’s Clinical Operations department. which deals with implementation of
operations policies, budget planning and working with medical and nursing management team
to uphold healthcare standards.
The Incident
3

Investigations revealed that, on 14 May 2020, Employee A received a phishing email

containing a hyperlink to a website with a further link to another website seeking his account
credentials. The hacker is believed to have obtained Employee A’s account credentials in this
way. Thereafter, the hacker accessed Employee A’s email account (the “Email Account”) and
synchronised the mailbox on 17 May 2020. In doing so, the hacker is believed to have
downloaded all the data stored in the Email Account in its entirety. The hacker also used
Employee A’s email account to send phishing emails to 1,039 external business contacts of the
Organisation, and 9 email accounts belonging to persons within the Organisation. Whilst these

phishing emails contained a link to a phishing webpage, they did not disclose any personal data
collected from the Email Account.
4

The Email Account comprised of 23,145 emails containing the personal data of

approximately 500 individuals (i.e. patients, employees and third parties):
(a)

Age

(b)

Arrear sum owed (22 patients affected)

(c)

Bank account number

(d)

Curriculum vitae

(e)

Date of birth

(f)

Data subject access request form (for 1 Singapore Police Force officer)

(g)

Information on the patient's family status and any psycho-social issues faced by the
patient

(h)

Dialysis readings

(i)

Email address

(j)

Emergency contact numbers of nurses

(k)

Education certificate(s)

(l)

Foreign Identification Number

(m)

Headshot photo

(n)

Health screening virology report of the Organisation’s nurses (25 nurses affected)

(o)

Household income band

(p)

Marriage certificate; and

(q)

Medical condition (8 patients affected)
(collectively, the “Affected Data”)

Security Measures prior to the Incident
2

At the time of the Incident, the work email accounts of the Organisation’s employees

were hosted on Microsoft Office 365, and the employees were able to access their email
accounts through the internet via a browser, ie web-accessible email or webmail. The following
security arrangements were in place to protect the email accounts from unauthorised access:
(a)

The password policy requires a minimum of 8 alphanumeric characters, including
upper and lower cases, and a special symbol.

(b)

A maximum of 3 unsuccessful login attempts before email accounts were locked out.

(c)

Deployed Microsoft’s Advanced Threat Protection (“ATP”) email filtering service,
with the ATP anti-phishing feature turned on.

(d)

Deployed Sender Policy Framework (“SPF”) and Domain Keys Identified Mail
(“DKIM”) email authentication protocols.

In addition, the Organisation also had various storage protection and network protection

measures. This included a web isolation tool from Menlo Security, and an appointed Managed
Security Service Provider (“MSSP”) that performs security monitoring round the clock.
7

In relation to its employees, the Organisation implemented a range of measures to

increase data protection awareness, including:
(a)

Issuing a policy manual which defined the standards for proper usage of all computing
and network resources by employees, and how employees should handle suspicious
emails;

(b)

Conducted training workshops in 2017 and 2018 in relation to the Personal Data
Protection Act 2012 (“PDPA”) for its internal stakeholders, which included a segment
on cybersecurity covering the topic of suspicious emails;

(c)

Conducting a phishing simulation exercise in 2019, which Employee A participated
in;

(d)

E-learning modules on cyber-security and the PDPA, which Employee A completed
in March 2020;

(e)

Sending regular emails and alerts targeted at increasing cybersecurity awareness to its
employees; and

(f)

Deploying cybersecurity awareness screensavers on all of the Organisation’s
computers.

Remedial Measures
8

After the Incident, the Organisation carried out the following remedial and rectification

measures:
(a)

Implemented additional email account security requirements for webmail access in the
form of two-factor authentication (“2FA”) on 22 May 2020;

(b)

Appointed a third-party service provider to conduct daily scans for communication
relating to the Incident on platforms across all media; and

(c)

Notified affected individuals of the Incident on 24 July 2020 and offered the affected
individuals subscription to an identity theft service to identify trading or selling of their
personal data on the dark web.

Findings and Basis for Determination
Whether the Organisation had contravened section 24 of the PDPA
9

Based on the circumstances of the Incident as set out above, the Commission’s

investigation centred on whether the Organisation had breached its obligation under section 24
of the PDPA 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 (“Protection Obligation”).
10

For the reasons set out below, it is determined that the Organisation failed to implement

reasonable security arrangements to protect the Affected Data from the risk of unauthorised
access by failing to implement reasonable access controls to its employees’ webmail accounts.
11

In determining what constitutes reasonable security steps or arrangements, an

organisation should have regard to the nature of the personal data in its possession and control,
4

as well as the impact that the disclosure of the data might have on the affected persons. As
stated in the Commission’s Advisory on Key Concepts in the PDPA1:
“There is no ‘one size fits all’ solution for organisations to comply with the Protection
Obligation. Each organisation should consider adopting security arrangements that are
reasonable and appropriate in the circumstances, for example, taking into consideration
the nature of the personal data, the form in which the personal data has been collected
(e.g. physical or electronic) and the possible impact to the individual concerned if an
unauthorised person obtained, modified or disposed of the personal data. For example,
in the employment context, it would be reasonable to expect a greater level of security
for highly confidential employee appraisals as compared to more general information
about the projects an employee has worked on.
In practice, an organisation should:
a)

design and organise its security arrangements to fit the nature of the personal
data held by the organisation and the possible harm that might result from a
security breach;

identify reliable and well-trained personnel responsible for ensuring information
security;

implement robust policies and procedures for ensuring appropriate levels of
security for personal data of varying levels of sensitivity; and

be prepared and able to respond to information security breaches promptly and
effectively.

In addition, it might be useful for organisations to undertake a risk assessment exercise
to ascertain whether their information security arrangements are adequate. In so doing,
the following factors may be considered:
a)

the size of the organisation and the amount and type of personal data it holds;

See sections 17.2 – 17.3 of Advisory Guidelines on Key Concepts in the PDPA (Rev 1 February 2021)

who within the organisation has access to the personal data; and

whether the personal data is or will be held or used by a third party on behalf of
the organisation.”
(emphasis added)

Where the personal data held by the organisation or particular employees are sensitive

and may cause damage to affected individuals if compromised, strong access control measures,
including robust authentication measures, are important safeguards. On top of basic
authentication measures such as implementing a proper password policy and password
expiration mechanism, strengthened measures such as two-factor authentication (“2FA”)
should be considered for webmail accounts with sensitive personal data, such as personal data
relating to health and finances. As stated at paragraphs [7.3] and [7.4] of the Commission’s
Guide to Securing Personal Data in Electronic Medium2:
“7. 3. The strength of authentication, such as password requirements or other
mechanisms for access to personal data, should depend on the potential damage
to the individual, such as potential damage to reputation or finances, if such
personal data is compromised…
7.4

More secure authentication methods include two-factor or multi-factor

authentication. These involve the use of a combination of information that the user
knows, such as a password or PIN, and an object that only the user possesses, such
as a digital key, token or smart card, or a unique physical trait, such as the use of
fingerprints in biometric technology. The use of multi-factor authentication
increases confidence in the identity of the user accessing the system.”
[emphasis added]
13

Having regard to the nature of personal data handled by the Organisation in its daily

operations, it had higher-level security needs that had to be met when discharging its Protection
Obligation. The Organisation is one of Singapore’s most prominent non-profit health
organisations and a key provider of subsidised dialysis treatment, with a significant number of
2

Guide to Securing Personal Data in Electronic Medium (revised Jan 2017)

patients under its care. Given the nature of its operations, the Organisation’s employees
routinely handle the medical data of its patients and financial data relating to the processing of
patient subsidies. The vulnerability of its employees’ email accounts (including the Email
Account) is made more acute by the fact that they are web-accessible. In this regard, the
Organisation should have conducted a risk assessment to identify the employee email accounts
that warranted a more robust authentication process by virtue of the sensitivity of the personal
data expected to be received in or sent from their email accounts.
14

As stated at 4 above, the Email Account contained the personal data of approximately

500 individuals. A subset of the Affected Data included sensitive personal data such as the
medical conditions of patients, arrears owed and health screening virology reports of some of
the Organisation’s nurses. In this regard, even though the Organisation did put in place a host
of technical measures and processes to address phishing risks prior to the Incident, we are of
the view that these security steps and arrangements did not satisfy the standard required under
section 24 of the PDPA, , for the reasons set out below, especially when the nature of the
personal data routinely handled by the Organisation is considered.
15

First, the Organisation did not adopt a risk-based approach to identify employees whose

roles and functions required them to handle sensitive personal data and strengthen the access
control measures to their email accounts.
16

Second, in relation to the email accounts of the employees who handle sensitive

personal data (in particular, Employee A) in their daily work, the Organisation also did not
implement more secure authentication processes access control measures to their email
accounts prior to the Incident. As stated in paragraph 5, the Organisation’s access control
requirements were confined to a password policy and the locking out of email accounts after 3
unsuccessful login attempts. These measures are too basic and inadequate to safeguard webmail
accounts from the threat of hackers seeking to access them from the internet, and left the
personal data contained therein vulnerable to unauthorised access and exfiltration. Examples
of more secure authentication methods include 2FA, which the Organisation eventually
implemented only after the Incident had occurred. If 2FA had been implemented earlier, this
would have ensured that the use of stolen credentials such as passwords would not, per se, be
sufficient to access the account.

In the premises, the Organisation has breached the Protection Obligation.

The Deputy Commissioner’s Decision
18

In determining whether any directions should be imposed on the Organisation under

section 48I of the PDPA, and/or whether the Organisation should be required to pay a financial
penalty under section 48J of the PDPA, the Commission considered the factors listed at section
48J(6) of the PDPA, and gave particular weight to the following mitigating factors:
Mitigating Factors
(a)

The Organisation had cooperated fully with the Commission during its

investigations;
(b)

The Organisation had put in place extensive measures to prevent phishing and

educate its employees about data protection;
(c)

The Organisation took prompt remedial actions following the Incident,

including notification of the affected individuals; and
(d)

The Organisation had conducted various data protection and cybersecurity

training for its employees.
19

Having considered all the mitigating factors listed above, the Organisation is

administered a warning in respect of its breach of the Protection Obligation. No other directions
are necessary in view of the remedial actions already taken by the Organisation.

YEONG ZEE KIN
DEPUTY COMMISSIONER
FOR PERSONAL DATA PROTECTION

",Warning,4095cd546dacd60ce1e477d8e6d816e126775088
49,49,1,952,Directions were issued to J & R Bossini Fashion for breaches of the PDPA in relation to the transfer of Singapore-based individuals’ personal data to its parent company in Hong Kong and the protection of its employees’ personal data stored in its servers in Singapore.,"[""Protection"", ""Transfer Limitation"", ""Directions"", ""Wholesale and Retail Trade""]",2021-10-14,https://www.pdpc.gov.sg/-/media/Files/PDPC/PDF-Files/Commissions-Decisions/Decision---J--R-Bossini-Fashion-Pte-Ltd---18082021.pdf,"Protection, Transfer Limitation",Breach of the Protection and Transfer Limitation Obligations by J & R Bossini Fashion,https://www.pdpc.gov.sg/all-commissions-decisions/2021/10/breach-of-the-protection-and-transfer-limitation-obligations-by-j-r-bossini-fashion,2021-10-14,"PERSONAL DATA PROTECTION COMMISSION

[2021] SGPDPC 9

Case No. DP-2006-B6440

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

And

J & R Bossini Fashion Pte Ltd
… Organisation

DECISION

J & R Bossini Fashion Pte Ltd
[2021] SGPDPC 9
Yeong Zee Kin, Deputy Commissioner — Case No. DP-2006-B6440
18 August 2021

Introduction

On 13 June 2020, J & R Bossini Fashion Pte Ltd (“the Organisation”) notified the

Personal Data Protection Commission (“the Commission”) of a ransomware attack which had
affected the IT systems of the Organisation’s group of companies on or around 27 May 2020
(“the Incident”). The Commission commenced investigations to determine whether the
circumstances relating to the Incident disclosed any breaches by the Organisation of the
Personal Data Protection Act 2012 (“PDPA”).
Facts of the Case

The Organisation is a company incorporated in Singapore, and a subsidiary of Bossini

International Holdings Limited, a company listed on the Stock Exchange of Hong Kong
(“Bossini Holdings”). Bossini Holdings and its subsidiaries (“the Group”) are in the business
of garment retail and brand franchising.

The Group’s IT systems and infrastructure across different regions (including

Singapore) are centrally managed by Bossini Holdings from Hong Kong. While most of the
Group’s production servers are located in Hong Kong, at the material time, the Organisation
maintained two servers and various workstations for its staff in Singapore which were
connected to the Group’s network in Hong Kong by way of a virtual private network (“VPN”).

Personal data collected by the Organisation

Sometime prior to 2017, the Organisation collected personal data from customers and

prospective customers in Singapore for the purposes of administering a customer loyalty
programme. The personal data collected comprised of each individual’s:
(a)

Name;

(b)

NRIC number,

(c)

Phone number,

(d)

Email address,

(e)

Residential address,

(f)

Date of birth; and

(g)

Gender.

(collectively, “the Customer Data”)

The Customer Data was initially stored locally by the Organisation in its servers in

Singapore. The Organisation transferred the Customer Data out of Singapore to a server in
Hong Kong around July 2017, as part of a Group level consolidation exercise with a view to
hosting the data in a cloud environment in the future.

Other than the Customer Data, the Organisation also collected and stored personal data

pertaining to its employees in its Singapore servers. This included each employee’s:

(a)

Name;

(b)

NRIC number,

(c)

Phone number,

(d)

Email address,

(e)

Residential address,

(f)

Date of birth;

(g)

Gender;

(h)

Marital status;

(i)

Salary details;

(j)

Bank account details, and

(k)

Medical claims records.

(collectively, “the Employee Data”)

The Incident

Sometime before 27 May 2020, attackers gained access to the Group’s network in Hong

Kong by exploiting a vulnerability in the Group’s off-the-shelf VPN software. The
vulnerability allowed the attackers to extract valid VPN credentials and bypass the Group’s
perimeter network security measures.

The vulnerability exploited by the attackers had been fixed by a patch released by the

VPN software developer in September 2019. However, Bossini Holdings had not deployed the
patch for the Group as at the time of the Incident on 27 March 2020 (i.e. nine months later).
The patch was subsequently deployed after the Incident on 3 June 2020.

After gaining a foothold into the Group’s network in Hong Kong, the attackers moved

laterally across the Group and compromised various administrative and user accounts to
conduct reconnaissance and escalate privileges. Eventually, with Group-level administrative
privileges, the attackers disabled endpoint security systems across the Group and executed the
ransomware attack.

The personal data of approximately 200,000 of the Group’s customers stored in the

Hong Kong server was encrypted and rendered inaccessible in the Incident. Relevantly, this
included the Customer Data of 154,213 customers originally collected by the Organisation in
Singapore. Of this, the Customer Data of at least 14,082 Singapore customers was exfiltrated
and exposed on the dark web. The Employee Data of 120 of the Organisation’s employees
stored in the servers in Singapore was similarly encrypted and rendered inaccessible in the
Incident.

All backups of the Customer Data and Employee Data maintained by Bossini Holdings

and the Organisation were affected and encrypted in the Incident, and no data restoration was
possible.

Remedial actions

Following the Incident, the remedial actions of Bossini Holdings and the Organisation

included:

(a)

Appointing a leading cybersecurity vendor to contain the impact of the Incident

and investigate its causes;
(b)

Publishing a data breach announcement on the Group’s website and via the

Stock Exchange of Hong Kong;
(c)

Notifying affected customers via the email addresses provided when registering

for the customer loyalty programme;
(d)

Blocking the IP addresses used by the attackers in the Incident and restricting

outbound network traffic to limit the ability of any malware in the Group’s network to
“call back” to the attackers;
(e)

Upgrading the VPN software to patch the vulnerability;

(f)

Enforcing multi-factor authentication for all remote access via VPN;

(g)

Enforcing a password change for all user account passwords and resetting all

domain user credentials;
(h)

Performing a review to limit and restrict public-facing services on network

perimeters;
(i)

Performing vulnerability scanning for critical servers to identify and rectify

immediate risks;
(j)

Reviewing and enhancing endpoint protection tools;

(k)

Implementing monitoring of perimeter firewalls and planning upgrades to the

server firewalls; and

(l)

Engaging a third-party security operations centre to monitor the Bossini group’s

network infrastructure.

For completeness, the Privacy Commissioner for Personal Data, Hong Kong (“PCPD”)

was notified of the Incident by Bossini Holdings on 24 June 2020 and conducted its own
compliance check. The Commission was informed that the PCPD would not be proceeding
with any further investigations after considering the circumstances of the case and the remedial
measures taken by Bossini Holdings.

Findings and Basis for Determination

Based on the circumstances of the Incident, the Commission’s investigation focused

on:
(a)

Whether the Organisation had breached its obligation under section 26 of the

PDPA to transfer personal data to a country or territory outside Singapore in accordance
with requirements prescribed under the PDPA (the “Transfer Limitation Obligation”)
in respect of the Customer Data transferred to Hong Kong on 17 July 2017; and
(b)

Whether the Organisation had breached its obligation under section 24 of the

PDPA 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 “Protection
Obligation”) in respect of the Employee Data encrypted in the Organisation’s servers
in Singapore during the Incident.

For the reasons set out below, the Organisation was determined to have breached both

the Transfer Limitation and Protection Obligations.
7

As a preface to the discussion below, it is relevant to highlight that both of the

Organisation’s breaches were attributable to its failure to implement policies and practices to
meet its obligations under the PDPA, as required by section 12 of the PDPA (“the
Accountability Obligation”).

For corporate groups which engage in (i) centralisation of corporate functions involving

intra-group dataflows and/or (ii) “outsourcing” of data processing activities to another member
of the same group, policies and practices ought to be developed and implemented at the group
level for the benefit of all members of the group. As stated in Everlast Projects Pte Ltd and
others [2020] SGPDPC 20 (“Everlast”) at [13]:

“(O)rganisations operating as a group of companies may comply with the
Accountability Obligation through binding group-level written policies or intra-group
agreements that set out a common and binding standard for the protection of personal
data across all organisations in the same corporate group. These binding group-level
written policies or intra-group agreements are akin to binding corporate rules
(“BCRs”) imposed by an organisation on its overseas recipient of the personal data
(in compliance with the Transfer Limitation Obligation under Section 26(1) of the
PDPA), which oblige the overseas recipient to provide a standard of protection to the
transferred personal data that is at least comparable to that under the PDPA. When
the corporate group is a multinational corporation (“MNC”) and the Contracting
Organisation (i.e. a member of a corporate group) transfers personal data to an
overseas Servicing Organisation (i.e. an overseas member of the same corporate
group), the binding group-level written policies, intra-group agreements or BCRs
which meet the requirements of the Protection Obligation under section 24 of the PDPA

would also meet the requirements of section 26(1) of the PDPA (i.e. the Transfer
Limitation Obligation)”

Whether the Organisation breached the Transfer Limitation Obligation

As the Customer Data was transferred from Singapore to Hong Kong on 17 July 2017,

the requirements in Part III of the Personal Data Protection Regulations 2014 (“PDPR”) 1
governed the Organisation’s compliance with the Transfer Limitation Obligation.

Regulation 9(1)(b) of the PDPR requires an organisation that transfers personal data

outside of Singapore to take appropriate steps to ensure that the recipient of the personal data
is bound by legally enforceable obligations to provide the transferred personal data a standard
of protection at least comparable to that under the PDPA. Under regulation 10 of the PDPR,
such legally enforceable obligations can be imposed on the recipient organisation under (a) any
law (e.g. the law of the recipient country); (b) any contract between the parties2; (c) binding
corporate rules3; or (d) any other legally binding instrument.

In the present case, the Organisation transferred the Customer Data to Bossini Holdings

upon instruction and took no steps to ascertain whether the Customer Data would be accorded
a comparable level of protection. In this regard, the transfer of the Customer Data was not made
pursuant to any intra-group contracts, binding corporate rules, or other legally binding
instrument. Accordingly, the Organisation failed to comply with regulation 9(1)(b) of the
PDPR and was determined to have breached the Transfer Limitation Obligation.

For transfers which took place on or after 1 February 2021, the relevant requirements are those prescribed in
Part 3 of the Personal Data Protection Regulations 2021.
2
For example, see Cigna Europe Insurance Company S.A.-N.V. [2019] SGPDPC 18.
3
For example, see Singapore Technologies Engineering Limited [2020] SGPDPC 21.

Whether the Organisation breached the Protection Obligation

At the time of the Incident, Bossini Holdings had implemented group-level security

arrangements for all of the Group’s IT systems, including the Organisation’s servers in
Singapore. Notwithstanding, the Employee Data remained in the Organisation’s possession in
the servers in Singapore, and the Organisation bore the Protection Obligation in respect of the
same.

It is appreciated that a corporate subsidiary in the circumstances of the Organisation,

which is subject to group-level security arrangements managed centrally, may not have the
autonomy or power to respond independently to a multinational data breach incident.
Nevertheless, the standard of conduct expected of such organisations in order to comply with
the Protection Obligation is not onerous. The following principles have been established in past
decisions.
(a)

First, a subsidiary should not adopt group level data protection policies without

considering whether these need to be adapted to their circumstances and contexts: Tiger
Airways Singapore Pte Ltd and others [2017] SGPDPC 6 at [33]; and
(b)

Second, when there is centralisation of corporate functions, group level policies

should be put in place in order that roles and responsibilities are clear: Everlast.

These twin principles provide the guard rails to guide organisations for establishing

accountability within a group and how this should cascade. In gist, where there is centralisation
of corporate functions, group level policies establish the scope of centralisation and the
respective roles and responsibilities of members within the group. This is not dissimilar to a
situation in which a data controller outsources certain data protection responsibilities to an
external vendor. It is the data controller’s obligation to specify and document what
10

responsibilities the vendor has undertaken, failing which they remain those of the data
controller. Once the group level policies are established, the relevant content then needs to be
cascaded and adapted in the internal policies implemented by each member of the group at an
organisational level.

As a subsidiary in a multinational corporate group, it is accepted that the Organisation

had to implement the Group’s IT policies, including IT security practices. The reality is that its
ability to influence these IT policies and how these practices were implemented was likely to
also have been limited. Nevertheless in the present case, the Group had no group level policies,
intra-group agreements, or binding corporate rules spelling out the data protection
responsibilities of the respective members of the Group. This created uncertainty as to whether
Bossini Holdings or the Organisation was responsible for software patching and security testing
of the Organisation’s IT systems in Singapore.

It was also accepted that the security lapse and privilege escalation that enabled the

attackers to overcome the Organisation’s endpoint protections in the Incident occurred abroad
out of the control of the Organisation. If the Group had intended for Bossini Holdings to be
centrally responsible for developing, implementing, and maintaining security arrangements for
all of the Group’s IT systems (including those of the Organisation), this should have at least
been documented in a binding group-level written policy. There was no evidence of the same,
and accordingly, the Organisation continued to bear responsibility in relation to the Employee
Data in its possession.

In the circumstances, the Organisation was determined to have breached the Protection

Obligation.

The Deputy Commissioner’s Directions

Having considered all the relevant factors of this case, the Deputy Commissioner

hereby directs the Organisation to:
(a)

within 30 days from the date of the direction accompanying this decision, put

in place intra-group agreements, contracts, or binding corporate rules for compliance
with sections 24 and 26 of the PDPA; and
(b)

inform the Commission of the completion of the above within 7 days of

implementation.

YEONG ZEE KIN
DEPUTY COMMISSIONER
FOR PERSONAL DATA PROTECTION

",Directions,0705137f0dd7129af2528c049cc49cf5edda8502
50,50,1,952,"A financial penalty of $37,500 was imposed on Stylez for failing to put in place reasonable security arrangements to protect personal data of its customers and cease retaining data when the purpose of collection no longer exists. As a result, the personal data of its customers was publicly exposed. A direction was also issued to Stylez to develop and implement internal data protection policies and practices to comply with the PDPA.","[""Protection"", ""Accountability"", ""Retention Limitation"", ""Financial Penalty"", ""Directions"", ""Accommodation and F&B"", ""Database""]",2021-10-14,https://www.pdpc.gov.sg/-/media/Files/PDPC/PDF-Files/Commissions-Decisions/Decision---Stylez-Pte-Ltd---04082021.pdf,"Protection, Accountability, Retention Limitation","Breach of the Protection, Accountability and Retention Limitation Obligations by Stylez",https://www.pdpc.gov.sg/all-commissions-decisions/2021/10/breach-of-the-protection-accountability-and-retention-limitation-obligations-by-stylez,2021-10-14,"PERSONAL DATA PROTECTION COMMISSION

[2021] SGPDPC 8

Case No. DP-2001-B5645

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

And

Stylez Pte Ltd

… Organisation

DECISION

Stylez Pte. Ltd.
[2021] SGPDPC 8

Lew Chuen Hong, Commissioner — Case No. DP-2001-B5645
4 August 2021
Introduction
1

On 25 December 2019, a local newspaper reported that data from a quotation and

service comparison portal, iCompare.sg (“the Portal”), had been uploaded onto the Dark Web
(the “Incident”)1 . The Personal Data Protection Commission (“the Commission”)
commenced investigations into the Incident thereafter.
Facts of the Case
2

The Portal was created and operated by Stylez Pte Ltd (“Organisation”) at the material

time. In July 2016, the Organisation created a new database containing data from the Portal for
the purposes of testing a new function for the Portal in a separate test environment (the
“Testing Database”). The Testing Database was a text file comprising records of the Portal’s
renovation and interior design clients from 2009 to 2016 and was hosted on a cloud server
leased from a cloud storage service provider (“the Server”).
3

Investigations revealed that the data exposed in the Incident was accessed and

exfiltrated from the Testing Database some time before December 2019. A total of 9,983
individuals’ personal data, comprising their name, email address, and phone number were
exposed in the Incident.
4

The Portal’s production and backup databases were hosted on servers leased from a

different cloud service provider and were unaffected in the Incident.
1 https://www.straitstimes.com/singapore/local-renovation-database-exposed-on-dark-web

Remedial actions
5

Following the Incident, the Organisation took the following remedial actions:
a.

The Testing Database and the account from which it was hosted were deleted;

A malware scan was run on the Server, and all unnecessary files were removed;

The operating system of the Server was updated and the root password was
changed;

A website security scanning tool was installed to conduct security scanning of the
Portal; and

The individuals affected in the Incident were notified.

Findings and Basis for Determination
Whether the Organisation contravened the Protection Obligation
6

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

Firstly, the Testing Database was stored in a publicly accessible directory in the Server

without any access controls. This resulted in the Testing Database being directly accessible
from the Internet and crawled and indexed by search engines. This was a serious breach
considering the volume of personal data contained in the Testing Database.
8

In the course of investigations, the Organisation characterised this as a failure to

activate an anti-indexing function in the Server’s software, which could have prevented the
3

Testing Database’s URL from being indexed by search engines. This is incorrect. Even if the
anti-indexing function had been activated, this would only have prevented the Server’s
directory contents from being listed. The actual contents of any publicly listed directory on the
Server could still have been crawled and indexed by search engines. Crucially, anti-indexing
is not the same as access control and even if the Testing Database’s URL was not indexed, it
could have been accessed directly without the need for authentication. This failure to appreciate
the difference between anti-indexing and access control is a fundamental failing on the
Organisation’s part. Proper authentication measures (e.g. password protection, access
whitelisting) should have been implemented to control access to the Testing Database.
9

Secondly, privileged access to the Server (and in turn the Testing Database) was also

not adequately secured. Though the password for the IT administrator’s account was strong (16
characters with upper and lower alphabets, numeric and special symbols), there was no limit
imposed on the number of unsuccessful login attempts which could be made. This made the
account vulnerable to brute-force attacks. The password to the IT administrator’s account was
also stored in his email account in clear-text without the need for any two-factor authentication.
This significantly weakened the protection accorded to the Server by strong login credentials.
10

Thirdly, the Testing Data was stored in the Server in an unencrypted format for more

than two and a half years (i.e. from July 2016 to December 2019). While the Organisation
claimed that the Testing Data was subsequently used for other business purposes, in general,
production data (i.e. actual personal data) should not be held in less secure development
environments for extended periods of time. This is discussed further below in relation to the
Organisation’s breach of the Retention Limitation Obligation.
11

For the above reasons, it was determined that the Organisation breached the Protection

Obligation in respect of the personal data in the Testing Database.

Whether the Organisation contravened the Accountability Obligation
12

Section 12(a) of the PDPA requires an organisation to develop and implement policies

and practices that are necessary for the organisation to meet its obligations under the PDPA
(the “Accountability Obligation”).
13

While the Organisation had developed an external data protection policy which

communicated its purported data protection standards to customers and prospective customers,
it failed to develop and implement any corresponding internal data protection policies to give
effect to these externally communicated standards.
14

By way of illustration, the Organisation’s external data protection policy stated:
“We have developed guidelines and implemented procedures to govern the destruction
of personal data that are no longer required to fulfil the identified purposes.”

In fact, no such guidelines or procedures were implemented, and this made what was

communicated to the Organisation’s customers and prospective customers effectively an empty
promise. While the Organisation claimed that it had relied on verbal reminders to inform its
staff on the importance of data protection, these reminders were undocumented, and in any
event, inadequate.
16

An organisation will not be taken to have complied with the Accountability Obligation

merely because it publishes and communicates a data protection policy to external parties. Any
externally communicated data protection policy must be given the weight of the necessary
internal policies and documented practices to guide an Organisation’s employees on how to
comply with the PDPA in carrying out their work functions.
17

For this reason, the Organisation was determined to have breached the Accountability

Obligation.

Whether the Organisation contravened the Retention Limitation Obligation
18

Section 25 of the PDPA requires an organisation to cease retaining data in a form that

can identify the individual if the purpose of collection no longer exists, and if no business or
legal reason exists for retention (the “Retention Limitation Obligation”).
19

In this case, the explicit purpose of creating the Testing Database was to test a particular

new function for the Portal in a separate environment. That purpose no longer existed once the
testing had been completed, and it was for the Organisation to justify why it continued to retain
the Testing Database for any legal or business reasons.
20

The Organisation claimed that it had continued to retain the Testing Database for the

purposes of business analysis, namely, to analyse (i) users’ requirements to improve the
Organisation’s marketing strategy (i.e. specifications listed by users for their renovation or
interior design jobs such as property type, room type, budget etc); and (ii) details on when users
made enquiries via the Portal in order to optimise the timing of online advertising. The
Organisation claimed that it could not have used other sources of data (such as their production
or regular backup databases) for these purposes as there was a risk of causing inadvertent
contamination of those databases if so used.
21

This justification was not accepted. Simply put, the business analysis described by the

Organisation did not require retention of data that could identify individuals. Even if the
Organisation wanted to retain the data in the Testing Database for these new business purposes,
the data could have been aggregated or anonymised (i.e. with any personal identifiers removed)
which would have taken the data outside the scope of regulated personal data, and allowed it
to be used as unregulated anonymised data.
22

It was also doubted that the Organisation would have relied on historical data from as

early as 2009 to conduct customer behaviour and preference studies when it would have been
more commercially useful to conduct such studies based on more recent data. In any event, no

weight was placed on this factor in determining that the Organisation had failed to comply with
the Retention Limitation Obligation in respect of the personal data in the Testing Database.
23

Had the Organisation carried out what it claimed that it would do in its external data

protection policy (see [14] above), it may well have ceased retention of or at least anonymised
the data in the Testing Database before the Incident.

The Commissioner’s Directions
24

In determining whether to impose a financial penalty on the Organisation pursuant to

section 48J(1) of the PDPA, and if so, the amount of such financial penalty, the factors listed
at section 48J(6) of the PDPA were taken into account, as well as the following aggravating
and mitigating factors:
Aggravating Factors
(a)

The personal data of almost 10,000 individuals was publicly exposed in the

Incident;
(b)

The Testing Database contained records that were 10 years old at the time of

the Incident;
(c)

The Organisation misrepresented the standard of its internal data protection

policies and practices to external parties;
Mitigating Factors
(d)

The Organisation took prompt remedial actions after being notified of the

Incident; and
(e)

The Organisation was cooperative during the investigations.

Having considered all the relevant factors of this case including representations made

by the Organisation on 5 July 2021 after being notified of the Commissioner’s Preliminary
Decision, the Commissioner hereby:
(a)

Requires the Organisation to pay a financial penalty of $37,500 in 12 monthly

instalments by the due dates as set out in the notice accompanying this decision, 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)

Directs the Organisation to develop and implement internal data protection

policies and practices to comply with the PDPA within 60 days of the relevant direction
accompanying this decision, and to notify the Commission within 1 week of the
completion of this direction.

YEONG ZEE KIN
DEPUTY COMMISSIONER
FOR COMMISSIONER FOR PERSONAL DATA PROTECTION

","Financial Penalty, Directions",573fcfa5db4c96ff1bb6711b02e1ab2d1d9cd20a
51,51,1,952,Carousell was found not in breach of the PDPA in relation to incidents where threat actor accessed Carousell users' accounts due to credential stuffing.,"[""Not in Breach"", ""Others"", ""Password""]",2021-09-21,https://www.pdpc.gov.sg/-/media/Files/PDPC/PDF-Files/Commissions-Decisions/Decision---Carousell-Pte-Ltd---030821.pdf,,No Breach of the Protection Obligation by Carousell,https://www.pdpc.gov.sg/all-commissions-decisions/2021/09/no-breach-of-the-protection-obligation-by-carousell,2021-09-21,"PERSONAL DATA PROTECTION COMMISSION
Case No. DP-2105-B8350

In the matter of an investigation under section 50(1) of the
Personal Data Protection Act 2012
And
Carousell Pte. Ltd.

SUMMARY OF THE DECISION

1. On 14 May 2021, Carousell Pte. Ltd. (the “Organisation”) informed the Personal Data
Protection Commission of an unauthorized access to their users’ accounts due to credential
stuffing.

2. The Organisation was first alerted on 26 April 2021 when a user reported to the
Organisation that his account had been hijacked and there were attempts to make
unauthorised purchases. On 1 June 2021, the Organisation was alerted to another incident
involving the same modus operandi where legitimate credentials were used to log in to
users’ accounts and unauthorised purchases were made (collectively, the “Incident”).

3. The Organisation’s investigations indicated that the Incident was due to the threat actor(s)
obtaining the login details and passwords of some of their users due to an exposure of the
account details on another service provider’s platform. The threat actor(s) succeeded in

certain cases where the user used the same login and password for their account with the
Organisation and their compromised accounts with other provider’s platforms. After
successfully logging into the account, the threat actor(s) was able to perform actions as an
authorised user. The threat actor(s) would also have access to the data in an individual’s
account and modify the account settings.

4. The Organisation’s investigations found that there was no known compromise or
unauthorised access of information in other accounts that were stored in the same database.
At the time of the Incident, the Organisation had in place security arrangements including,
but not limited to, the following:

a. Users are informed when there is a change to the password, email or phone number
linked to their account, or when a new device is used to log in;

b. Training of account takeover model to identify and investigate likely account takeovers;

c. Card transactions that meet a certain fraud score are blocked or reviewed;

d. One Time Password required to complete transactions for all card payments;

e. Regular review of policies and regular testing and review of risk rules based on fraud
trends, seasonality, regulation and all related indicators;

f. Company-wide training and educational newsletters to increase staff awareness on
security and data protection requirements; and

g. Conduct annual penetration security assessment.

5. I am of the view that the Organisation had adopted reasonable standards for protecting
personal data in their customer accounts on an objective review of the measures that were
implemented at the time of the Incident. Further, the Organisation took prompt action to
mitigate the effects of the breach by suspending the compromised users accounts and force
password resets for affected users. Emails were sent to alert affected users of suspicious
login in their accounts. DBS Paylah! Express Checkout was disabled for affected users
whose accounts were suspected to have been compromised.

6. The Organisation also reviewed the Incident, and took remedial measures to enhance the
robustness of their security measures, including but not limited to the following:

a. Blocked suspicious IP addresses;

b. Added rules into third party fraud detection tool to prevent account takeovers;

c. Implemented a mandatory 2FA verification, via email, in the event there is a change
detected in the user’s device ID across all platforms; and

d. Efforts to educate users and raise awareness to fight against phishing attempts were
enhanced.

7. Having found that at the time of the Incident, the Organisation had implemented reasonable
security arrangements to protect the personal data under its control, I conclude that the
Organisation did not breach its Protection Obligation under the Personal Data Protection
Act.

",Not in Breach,da3c0f91c3b8e24ee0b6a4d9f85d596df8a36ab7
52,52,1,952,"A financial penalty of $9,000 was imposed on Sendtech for failing to put in place reasonable security arrangements to protect personal data. This resulted in an unauthorised access of the personal data stored in their Amazon Web Services account.","[""Protection"", ""Financial Penalty"", ""Admin and Support Services"", ""Password""]",2021-09-21,https://www.pdpc.gov.sg/-/media/Files/PDPC/PDF-Files/Commissions-Decisions/Decision---Sendtech-Pte-Ltd---220721.pdf,Protection,Breach of the Protection Obligation by Sendtech,https://www.pdpc.gov.sg/all-commissions-decisions/2021/09/breach-of-the-protection-obligation-by-sendtech,2021-09-21,"PERSONAL DATA PROTECTION COMMISSION

Case No. DP-2102-B7884

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

And

Sendtech Pte. Ltd.
… Organisation
SUMMARY OF THE DECISION

On 13 February 2021, Sendtech Pte. Ltd. (the “Organisation”) informed the Personal
Data Protection Commission (the “Commission”) of a data breach incident. There was
an unauthorized access to the Organisation’s Amazon Web Services (“AWS”) account
via an access key (the “Incident”).

The Organisation became aware of the Incident on 10 February 2021 when its AWS
account was shut down due to unusual account activity. The cause of Incident was a
compromised AWS access key. This access key was created in 2015 when the
Organisation was developing the backend of its server in its incipient stages. This AWS
access key had not been rotated or changed since 2015. The Organisation suspected that
the AWS could have been compromised through its former or current employees. First,
all former developers had access to this key and some could still have the source code on

their computers. Second, as most of the employees are working from home, it is possible
that the AWS access key was compromised if the employees had accessed internet
through a public WiFi connection.

With this compromised AWS access key, the attacker gained admin privileges, created
another admin account and queried the buckets storing personal data. As a result, the
personal data of 64,196 customers and 3,401 contractors and the contractors’ employees
were accessed. There was no evidence of data exfiltration. For the customers, the
personal data included the email address, contact number, home address and last four
digits of the debit or credit card. For the contractors and their employees, the personal
data included profile photo and copies of the NRIC or work permit (front and back).

The Organisation took the following remedial measures after the Incident:

a. Rotated all access keys;
b. Changed passwords for all servers;
c. Enhanced its audit trail on AWS buckets to log all read and write operation at the
object level;
d. Checked and verified that its Github repositories was set to “Private”;
e. Engaged cybersecurity consultants to carry out assessment of its security setup and
advise on improvements to the security measures; and
f. Developed new cybersecurity policies and processes which specifically include
measures for credentials management.

In its representations to the Commission, the Organisation admitted to having breached
the Protection Obligation under section 24 of the Personal Data Protection Act (the
“PDPA”), and requested for the matter to be dealt with in accordance with the
Commission’s Expedited Decision Procedure.

The Organisation admitted it did not have specific AWS policies for the assignment of
roles to rotate credentials. There was also a lack of detailed steps to manage credentials
access of outgoing staff. Hence, the credentials were not rotated or changed whenever
there are staff movement.

In the circumstances, the Organisation is found to have breached section 24 of the PDPA.

On 23 June 2021, the Organisation was notified of the Commission’s intention to impose
a financial penalty of $10,000 based on the Commission’s consideration of the factors
listed under section 48J(6) of the PDPA, and the circumstances of this case, in particular
(i) the Organisation’s upfront voluntary admission of liability which significantly
reduced the time and resources required for investigations; and (ii) the prompt remedial
actions undertaken by the Organisation. The Organisation was invited to make
representations. Having considered the Organisation’s representations dated 25 June
2021 to reduce the financial penalty payable and to allow the Organisation to pay the
financial penalty by way of an instalment plan the Deputy Commissioner hereby directs
the Organisation to:

a. Pay a financial penalty of $9,000 in 12 instalments by the due dates as set out below,
failing which the full outstanding amount shall become due and payable immediately
and 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:

1st instalment of $750 on 1 September 2021;

ii.

2nd instalment of $750 on 1 October 2021;

iii.

3rd instalment of $750 on 1 November 2021;

iv.

4th instalment of $750 on 1 December 2021;

5th instalment of $750 on 1 January 2022;

vi.

6th instalment of $750 on 1 February 2022;

vii.

7th instalment of $750 on 1 March 2022;

viii. 8th instalment of $750 on 1 April 2022;

ix.

9th instalment of $750 on 1 May 2022;

10th instalment of $750 on 1 June 2022;

xi.

11th instalment of $750 on 1 July 2022; and

xii.

12th instalment of $750 on 1 August 2022.

In view of the remedial actions taken by the Organisation, the Commission will not issue
any directions under section 48I of the PDPA.

",Financial Penalty,cd74c714c427c34a4021513b29355c8019982bf8
53,53,1,952,"A financial penalty of $13,500 was imposed on SAP Asia for failing to put in place reasonable security arrangements to protect personal data of its former employees. This resulted in an unauthorised disclosure of the personal data to unintended recipients.","[""Protection"", ""Financial Penalty"", ""Admin and Support Services"", ""Vendor""]",2021-09-21,https://www.pdpc.gov.sg/-/media/Files/PDPC/PDF-Files/Commissions-Decisions/Decision---SAP-Asia-Pte-Ltd---310721.pdf,Protection,Breach of the Protection Obligation by SAP Asia,https://www.pdpc.gov.sg/all-commissions-decisions/2021/09/breach-of-the-protection-obligation-by-sap-asia,2021-09-21,"PERSONAL DATA PROTECTION COMMISSION

[2021] SGPDPC 6

Case No. DP-2004-B6180

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

SAP Asia Pte. Ltd.
… Organisation

DECISION

SAP Asia Pte. Ltd.
[2021] SGPDPC 6

Lew Chuen Hong, Commissioner — Case No. DP-2004-B6180
30 July 2021
Introduction
1

On 1 April 2020, the Personal Data Protection Commission (“the Commission”)

received a complaint that SAP Asia Pte. Ltd. (“the Organisation”) had disclosed the payroll
information of some of its former employees to the wrong email recipients (“the Incident”).
The Commission commenced investigations into the Incident thereafter.
Facts of the Case
2

At the material time prior to the Incident, the Organisation had engaged an external

vendor (“the Vendor”) to provide IT solutions for its human resources and payroll system
(“the HR System”). The Organisation’s process of issuing payslips to its employees had been
automated as part of the HR System. However, when payslips needed to be issued to
individuals who had already left the employment of the Organisation (e.g. final payslips,
reimbursements of expenses etc), this could not be done via the HR System. Such payslips
needed to be separately generated by the Organisation’s human resources department and
emailed to the former employees at their personal email addresses. The Organisation was keen
to automate the process of issuing payslips to former employees as part of the HR System, and
sometime around April 2019, requested the Vendor to develop a new programme within the
HR System for this purpose (“the Programme”).
3

The Organisation had intended to use the Programme to generate and email multiple

payslips to multiple former employees simultaneously in one execution of the Programme

SAP Asia Pte. Ltd.

[2021] SGPDPC 6

(“Multiple Payslip Issuance”). However, as will be discussed below, this intention was not
properly communicated to the Vendor, and the Programme was designed on the incorrect
understanding that only a single payslip would need to be issued to a single employee at a time
(“Single Payslip Issuance”).
4

The Organisation executed the Programme for the first (and only) time on 31 March

2020 to generate and deliver payslips to 43 former employees at their personal email addresses.
Believing the Programme to be capable of Multiple Payslip Issuance, the Organisation’s
representative selected all 43 former employees to be issued payslips in one selection screen of
the Programme and executed the process. As the Programme had not been designed to be able
to properly execute Multiple Payslip Issuance, this execution of the Programme resulted in 29
out of the 43 former employees receiving their own payslip as well as the payslips of other
employees. By way of illustration:
(a)

The 1st former employee in the selection received only their own payslip.

(b)

The 2nd former employee in the selection received their own payslip as well as

the payslip of the 1st former employee.
(c)

The 3rd former employee in the selection received their own payslip as well as

the payslips of the 1st and 2nd former employees.
5

13 of the 43 former employees had not provided the Organisation with valid email

addresses and did not receive any emails with payslips. However, the payslips of these 13
former employees were still generated and disclosed to the 29 other former employees when
the Programme was executed on 31 March 2020.
6

In all, the personal data of 43 former employees of the Organisation was improperly

disclosed in the Incident. The disclosed personal data comprised each of the former
employees’:
1

SAP Asia Pte. Ltd.

[2021] SGPDPC 6

(a)

Name;

(b)

NRIC or FIN number;

(c)

Employment number;

(d)

Bank account number;

(e)

Monthly basic salary;

(f)

Detailed breakdown of current payment; and

(g)

Year-To-Date earnings and deductions.

Remedial actions
7

Following the Incident, as part of remedial actions, the Organisation:
(a)

Emailed all 43 former employees on 1 April 2020 informing them about the

error and requesting each of them to delete the payslips which were not intended to be
emailed to them;
(b)

Followed up with the former employees over phone to confirm deletion of the

other payslips and received confirmation from 39 of the 43 former employees affected;
(c)

Disabled the Programme and reverted to manually generating and emailing

payslips to former employees; and
(d)

Agreed on continuous process improvements with the Vendor with clear

communicated requirements.

SAP Asia Pte. Ltd.

[2021] SGPDPC 6

Findings and Basis for Determination
Whether the Organisation contravened the Protection Obligation
8

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

In this case, the Organisation, a data controller, engaged the Vendor to develop a new

feature for its IT systems which processed personal data in its possession (i.e. the Programme).
The development of the Programme had obvious implications for the way in which the former
employees’ personal data would be processed. However, in developing the Programme, the
Vendor did not process personal data on behalf of the Organisation and was not the
Organisation’s data intermediary in this regard. Accordingly, the Protection Obligation in
respect of the former employees’ personal data was borne solely by the Organisation.
10

In the context of the Programme’s development, the Organisation’s responsibilities

under the Protection Obligation included ensuring that:
(a)

The specifications provided to the Vendor accurately reflected the intended use

of the IT feature being developed; and
(b)

Pre-launch testing of the new feature was accurately scoped to simulate the full

range of intended use of the new feature.
11

For the reasons set out below, the Organisation failed both of these responsibilities.

SAP Asia Pte. Ltd.

[2021] SGPDPC 6

Failure to adequately specify requirements for the Programme
12

It is a data controller’s responsibility to ensure that external vendors who are engaged

to modify its IT systems know the scope of their work. As stated in (1) Smiling Orchid (S) Pte
Ltd; (2) T2 Web Pte Ltd; (3) Cybersite Services Pte Ltd; (4) East Wind Solutions Pte Ltd [2016]
SGPDPC 19 at [51]:
“ Data controllers that (engage) outsourced service providers have to be clear about
the nature and extent of services that the service provider is to provide. There 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.”
13

This does not mean that all organisations will be expected to be able to give detailed

technical instructions to their IT vendors. As clarified in MDIS Corporation Pte Ltd
[2020] SGPDPC 11 at [14]:
“While an organisation may not have — or need to have — the requisite level of
technical expertise, a responsible organisation would have engaged competent service
providers and made genuine attempts to give proper instructions. The Organisation is
only expected to articulate its business requirements as owner of the system, which
the service provider can translate into technical requirements. In addition, as the data
controller, the Organisation is required to exercise reasonable oversight to ensure that
its instructions are carried out.”
[emphasis added]
14

In previous enforcement decisions, the Commissioner has held organisations in breach

of the Protection Obligation for failing to properly communicate business requirements for
design changes to IT features:
4

SAP Asia Pte. Ltd.

(a)

[2021] SGPDPC 6

In Singapore Cricket Association and another [2018] SGPDPC 19, the

organisation engaged a vendor to redesign its website, including certain pages featuring
profiles of its registered players. The organisation’s requirements were conveyed to the
vendor piecemeal - in meetings, through phone calls, and over text messages. As a
result, the vendor misunderstood the intended contents for the player profile pages and
incorrectly disclosed around 100 players’ personal data including NRIC numbers and
contact information as part of the redesigned website.
(b)

The

Central

Depository

(Pte)

Limited

another

[2019] SGPDPC 24, the organisation engaged a vendor to develop software to generate
and issue notification letters to its customers. However, the organisation failed to
provide the vendor with clear specifications and representative test data that covered
the full range of data to be processed and the various processing scenarios. As such, the
vendor incorrectly assumed that a particular dataset would always have 4 lines of data
to extract for each letter, when in fact, that dataset could have also had 1, 2, or 3 lines
of data. This resulted in a design error that caused the inadvertent disclosure of 1,358
customers’ personal data to the wrong recipients when the software was deployed.
(c)

In Horizon Fast Ferry Pte Ltd [2019] SGPDPC 27, a ferry operator engaged a

vendor to redesign its booking website. There was no written contract between the
parties, and all instructions and requirements for the redesign were conveyed verbally
or over text messages. As a result, the vendor misunderstood the scope of the redesign
and incorrectly imported an auto-population feature from one of the organisation’s
internal systems to the redesigned website. This caused the booking form on the
redesigned website to automatically populate all fields in the form whenever a passport
number that matched an entry in the organisation’s passenger database was entered. As
a result, the personal data of close to 300,000 of the organisation’s passengers was
exposed to the risk of unauthorised access.

SAP Asia Pte. Ltd.

[2021] SGPDPC 6

In the present case, the Organisation failed to make clear to the Vendor that the

Programme was intended to be used for Multiple Payslip Issuance. This resulted in the Vendor
designing the Programme under the wrong impression that all that was required by the
Organisation was Single Payslip Issuance.
16

The misunderstanding between the Organisation and Vendor was attributable to the

Organisation’s instructions in relation to development of the Programme being brief and
ambiguous. The Organisation’s instructions to the Vendor were contained in a short service
request which read as follows:
“HI Team,
Can you please enhance the program (…) where by when i key in
the employee id, (…) then
A template of the email with the payslip is send to the selected employee?
Thanks!”
[emphasis added]
17

The request only referred to a payslip to be sent to a “selected employee” (i.e. in the

singular) and not multiple employees (i.e. plural).
18

This reference to using the Programme for a single employee (as opposed to multiple

employees) was repeated by the Organisation when later responding to clarifications sought by
the Vendor as to why payslips needed to be sent to external email addresses:
“HI (…),
The sending of email to private address is necessary as we are require to provide
payslip to ex employee when ever there is a payment. This is for employee who have
left the organization.
Thanks!”
6

SAP Asia Pte. Ltd.

[2021] SGPDPC 6

Apart from these communications, there was no other documentation of the Multiple

Payslip Issuance requirement. If the Organisation intended to use the Programme to send
payslips in a single instance to multiple former employees (i.e. Multiple Payslip Issuance) this
should have been clearly communicated as a required specification for the Programme. The
Organisation’s failure to properly communicate its business requirements to the Vendor
resulted in the Programme being inadvertently designed in an insecure way.
Failure to carry out adequate user acceptance testing
20

The Organisation’s failure to specify Multiple Payslip Issuance as a required

functionality of the Programme was compounded by its failure to include any Multiple Payslip
Issuance scenarios in its user-acceptance testing (“UAT”) for the Programme (i.e. testing
carried out prior to deploying the Programme for use as part of the HR System).
21

Pre-launch testing is an important means of identifying data protection risks before new

IT features are deployed in a live environment, and this has also been emphasised in the
Commission’s recently published handbook, How to Guard Against Common Types of Data
Breaches1:
“Most organisations fail to recognise that proper testing can help them to identify
defects in programming before a system is launched. Sufficient resources should be
allocated for testing, and a comprehensive UAT should ensure good test coverage of
scenarios including possible user journeys and exception handling. Organisations
should also ensure that the planned UAT scenarios match real-world usage. This can
be done through a comprehensive gathering of business requirements and identification
of relevant usage scenarios by potential users. These should be driven by the business
owner.”
1

https://www.pdpc.gov.sg/news-and-events/announcements/2021/05/handbook-on-how-to-guard-againstcommon-types-of-data-breaches-now-available

SAP Asia Pte. Ltd.

[2021] SGPDPC 6

[emphasis added]
22

In previous enforcement decisions, organisations have been held in breach of the

Protection Obligation for failing to properly scope pre-launch testing to simulate real-world
use of new IT features:
(a)

In Option Gift Pte Ltd [2019] SGPDPC 10, the organisation developed a

programme to send email confirmations to persons who had made gift redemption
requests. The programme was intended to send a single email confirmation to each
recipient. However, a coding error meant that while the first email was sent to the first
recipient (as intended), the second email was sent to both the first and second recipient
and so on (i.e. a similar type of error as in the Incident as described at [4] above). The
organisation’s UAT was found to be inadequate as the programme had only been tested
by sending confirmation emails to the same internal email address. There was no testing
that simulated the intended use of the programme to send emails to multiple recipients.
(b)

In AIA Singapore Private Limited [2019] SGPDPC 20, the organisation

employed an automated system to generate and send different types of letters to its
customers. A fix had been deployed to correct an earlier programming error but ended
up introducing a further error. When different types of letters were processed in one
batch, the further error caused letters to be sent to the wrong recipients. The
organisation’s testing prior to deploying the fix had only simulated scenarios in which
one letter was generated at a time. However, this did not replicate the real-world use of
the system as letters were ordinarily generated and dispatched in batches.
(c)

In Grabcar Pte Ltd [2020] SGPDPC 14, an update deployed for the

organisation’s mobile application inadvertently exposed the personal data of some users
to the risk of unauthorised access by other users. The error arose because the effect of
the update on a particular caching mechanism had not been detected in testing. This
8

SAP Asia Pte. Ltd.

[2021] SGPDPC 6

was partly because the organisation failed to test the update in scenarios where multiple
users were accessing the application concurrently (which was a foreseeable real-world
scenario).
23

Similar to the above precedents, in the present case, the Organisation’s representative

only conducted 2 test scenarios as part of UAT, and both only involved Single Payslip Issuance.
The failure to test Multiple Payslip Issuance as part of UAT meant that the testing was
inadequate to simulate the Organisation’s intended use of the Programme, and the
Programme’s incapability of handling Multiple Payslip Issuance was not picked up at the
testing stage as it should have.
24

For the above reasons, the Organisation was determined to have breached the Protection

Obligation in respect of the former employees’ personal data disclosed in the Incident.
The Commissioner’s Directions
25

In determining whether to impose a financial penalty on the Organisation pursuant to

section 48J(1) of the PDPA, and if so, the amount of such financial penalty, the factors listed
at section 48J(6) of the PDPA were taken into account, as well as the following mitigating
factors:
Mitigating Factors
(a)

The Organisation took prompt remedial actions after being notified of the

Incident; and
(b)
26

The Organisation was cooperative during the investigations.

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

requires the Organisation to pay a financial penalty of $13,500 within 30 days from the date of
9

SAP Asia Pte. Ltd.

[2021] SGPDPC 6

the relevant notice accompanying this decision, 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.
27

No further directions are necessary on account of the remedial measures already taken

by the Organisation.

YEONG ZEE KIN
DEPUTY COMMISSIONER
FOR COMMISSIONER FOR PERSONAL DATA PROTECTION

",Financial Penalty,b1202a44badfb2a4eadf02786aeafab69a9a4136
54,54,1,952,"A financial penalty of $8,000 was imposed on Seriously Keto for failing to put in place reasonable security arrangements to protect the personal data stored in its server. This resulted in the data being subjected to a ransomware attack.","[""Protection"", ""Financial Penalty"", ""Accommodation and F&B"", ""Ransomware"", ""Vendor""]",2021-09-21,https://www.pdpc.gov.sg/-/media/Files/PDPC/PDF-Files/Commissions-Decisions/Decision---Seriously-Keto-Pte-Ltd---14072021.pdf,Protection,Breach of the Protection Obligation by Seriously Keto,https://www.pdpc.gov.sg/all-commissions-decisions/2021/09/breach-of-the-protection-obligation-by-seriously-keto,2021-09-21,"PERSONAL DATA PROTECTION COMMISSION
Case No. DP-2006-B6449
In the matter of an investigation under section 50(1) of the
Personal Data Protection Act 2012
And
Seriously Keto Pte. Ltd.
SUMMARY OF THE DECISION
1. On 16 June 2020, Seriously Keto Pte Ltd (the “Organisation”) notified the
Personal Data Protection Commission (the “Commission”) of a ransomware
infection that occurred on or about 15 June 2020 (the “Incident”). The affected
personal data comprised approximately 3,073 individuals’ names, addresses,
email addresses and telephone numbers (“the Affected Personal Data”).

2. The Organisation requested that the Commission investigate the Incident under its
Expedited Decision Procedure. In this regard, the Organisation voluntarily provided
and unequivocally admitted to the facts set out in this decision. It also admitted that
it was in breach of the Protection Obligation under section 24 of the Personal Data
Protection Act (the “PDPA”).

3. Investigations revealed the presence of an unprotected file in the Organisation’s
network infrastructure which contained unencrypted login credentials to access the
server containing the Affected Personal Data. The unprotected file could be located
by infrastructure scanning, and this provided a channel for unauthorised access to
the server. Server logs retrieved by the Organisation after the Incident indicated
that there had been unauthorised access to the file.

4. The Organisation admitted that it had failed to conduct any periodic security
reviews prior to the Incident which could have revealed the existence of the
unprotected file within its network infrastructure.

5. The Organisation had engaged a vendor to develop its e-commerce and
membership website and claimed to have relied on the vendor to make the
necessary security arrangements to protect the Affected Personal Data. However,
in this case, there were no clear business requirements (e.g. contractual
stipulations) specifying that the Organisation was relying on the vendor to
recommend and/or implement security arrangements to protect personal data
hosted in the e-commerce and membership website that the vendor was engaged
to develop. Protection of personal data in the possession or under the control lies
primarily with the Organisation, although it may contract the operations to a vendor
who is more knowledgeable and with expertise. To do so, the Organisation has to
be clear about the scope of outsourcing and the vendor has to also agree to do so.
In the absence of clear outsourcing, the responsibility to implement reasonable
security arrangements to protect the Affected Personal Data remained squarely
with the Organisation.

6. Overall, the Organisation admitted that it had failed to give due attention to
personal data protection prior to the Incident and had neglected to implement
reasonable security arrangements to protect the Affected Personal Data.

7. In the above circumstances, the Deputy Commissioner for Personal Data
Protection finds that the Organisation negligently contravened the Protection
Obligation under section 24 of the PDPA.

8. Following the Incident, the Organisation underwent a full security audit and
remedied vulnerabilities identified. The Organisation also set up a new website with
a more robust internal security infrastructure, implemented a mandatory password
change for all users of its new website, and activated a firewall to safeguard access
to the new website. It also engaged a cybersecurity vendor to develop further

measures and policies to strengthen its internal IT infrastructure. Additionally, the
Organisation committed to engaging consultants to improve its data protection
policies and outsource data protection functions.

9. The Organisation cooperated with the Commission’s investigation, admitted to its
breach of the Protection Obligation, and took prompt remedial action. There was
no evidence of exfiltration of the Affected Personal Data, and the Organisation was
able to restore the Affected Personal Data from a backup and did not lose any data
as a result of the Incident. The practice of having regular and separately located
data backup(s) is to be encouraged to prevent organisations from losing data to
ransomware.

10. Having considered the above circumstances and the factors listed at section 48J(6)
of the PDPA, the Deputy Commissioner for Personal Data Protection requires the
Organisation to pay a financial penalty of $8,000 within 30 days from the date of
the notice accompanying this decision, 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.

11. In view of the remedial actions taken by the Organisation, no other directions are
necessary.

",Financial Penalty,f96a9b453e14796f77b805ed107e916524839f6e
55,55,1,952,"A warning was issued to Specialized Asia Pacific for failing to put in place reasonable security arrangements to protect the personal data of 2,445 application users.","[""Protection"", ""Warning"", ""Others"", ""Mobile application""]",2021-09-21,https://www.pdpc.gov.sg/-/media/Files/PDPC/PDF-Files/Commissions-Decisions/Decision---Specialized-Asia-Pacific-Pte-Ltd---300721.pdf,Protection,Breach of the Protection Obligation by Specialized Asia Pacific,https://www.pdpc.gov.sg/all-commissions-decisions/2021/09/breach-of-the-protection-obligation-by-specialized-asia-pacific,2021-09-21,"PERSONAL DATA PROTECTION COMMISSION

Case No. DP-2101-B7826

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

And

Specialized Asia Pacific Pte Ltd
… Organisation

SUMMARY OF THE DECISION

On 29 January 2021, Specialized Asia Pacific Pte Ltd. (the “Organisation”) informed
the Personal Data Protection Commission of a data security incident involving the
Specialized Cadence application (the “Application”) that it developed, operated and
maintained.

The Organisation’s developing staff did not realize that the online development tool,
which was used to develop the Application, had a default privacy setting that made all
data created by users or developers “visible”, even though this had been stated in the
tool’s privacy rules. This default setting allowed the Application’s network traffic to be
intercepted and accessed using third-party security testing software that can be acquired
online. A member of the public had therefore been able to intercept and access the
personal data of the Application’s users by using a free version of such software (the

“Incident”). However, the risk of unauthorised access had been limited to parties who
knew how to use such security testing software to obtain access. This factored in the
enforcement outcome below (see paragraph 6 below).

The undetected default privacy setting of “visible” put the personal data of 2,445
individuals at risk of unauthorised access. The data affected included names, addresses,
dates of birth, telephone numbers, email addresses and gender.

Remediation by the Organisation encompassed turning off all access and use of the
Application by all external parties, including users, and changing the privacy setting from
“visible” to “hidden”. The Organisation also engaged a third-party IT security firm to
test and address any security and privacy issues relating to the Application, commenced
discussions with its IT application designers and employees involved to adopt ‘privacyby-design’ in future applications development.

The Protection Obligation in section 24 of the Personal Data Protection Act 2012 requires
that organisations understand the privacy policies and security features of all online tools
or software they choose to employ. This was established in published cases such as Re
GMM Technoworld Pte. Ltd. [2016] SGDPDPC 18. Organisations employing online
tools or other online software must set or reconfigure privacy policies and security
features to protect the personal data of application or website users. It would not be a
discharge of the Protection Obligation for an organisation to simply adopt, vis-à-vis

users, the same default privacy policies of online tools or software that do not protect the
personal data of users.

The Deputy Commissioner for Personal Data Protection therefore found the Organisation
in breach of the Protection Obligation under Section 24 of the Personal Data Protection
Act 2012. Upon consideration of the facts, including the limited exposure of the affected
data to those who knew how to use the above-mentioned third party software to access
such information via the default privacy setting, and the Organisation’s commitment to
improve its processes, a Warning was issued to the Organisation.

",Warning,bb6b30899dc237cbbb5ca65a53c42a6e8fc69444
56,56,1,952,Directions were issued to NUInternational Singapore and Newcastle Research and Innovation Institute for breach of the PDPA in relation to the transfer of Singapore-based individuals’ personal data to their ultimate parent company in the United Kingdom and related company in Malaysia.,"[""Transfer Limitation"", ""Directions"", ""Education"", ""Ransomware"", ""Consent""]",2021-09-21,https://www.pdpc.gov.sg/-/media/Files/PDPC/PDF-Files/Commissions-Decisions/Decision---NUI-and-NewRIIS--23062021.pdf,Transfer Limitation,Breach of the Transfer Limitation Obligation by NUInternational Singapore and Newcastle Research and Innovation Institute,https://www.pdpc.gov.sg/all-commissions-decisions/2021/09/breach-of-the-transfer-limitation-obligation-by-nuinternational-singapore-and-newcastle-research-and-innovation-institute,2021-09-21,"PERSONAL DATA PROTECTION COMMISSION

[2021] SGPDPC 5
Case No. DP-2009-B7011

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

And

(1) NUInternational Singapore Pte Ltd
(2) Newcastle Research and Innovation Institute Pte Ltd

… Organisations

DECISION

(1) NUInternational Singapore Pte Ltd; (2) Newcastle Research and
Innovation Institute Pte Ltd
[2021] SGPDPC 5

Yeong Zee Kin, Deputy Commissioner — Case No. DP-2009-B7011
23 June 2021

Introduction

On 17 September 2020 and 13 November 2020, the Personal Data Protection

Commission (the “Commission”) was notified of a ransomware attack relating to Newcastle
Research and Innovation Institute Pte Ltd and NUInternational Singapore Pte Ltd (collectively
known as the “Organisations”) in Singapore (the “Incident”).

Facts of the case

The ransomware infected, on or around 30 August 2020, (a) a database in the United

Kingdom, managed by the ultimate parent company of the Organisations (containing 1,083
records of Singapore-based individuals); and (b) a database in Malaysia, hosted by a related
company of the Organisations (containing 194 records of Singapore-based individuals). These
records containing personal data of the Singapore-based individuals were previously
transferred from the Organisations to the ultimate parent company in the United Kingdom and
the related company in Malaysia respectively. The Singapore-based individuals were a mix of
staff members, undergraduates and/or post-graduate students of the Organisations. Their

personal data (comprising names and user account identifications) were exfiltrated by the threat
actor.

Findings and Basis for Determination

Section 26(1) of the PDPA stipulates that an organisation shall not transfer any personal

data to a country or territory outside Singapore except in accordance with the requirements
prescribed under the PDPA to ensure that organisations provide a standard of protection to
personal data so transferred that is comparable to the protection under the PDPA (the
“Transfer Limitation Obligation”). The requirements mentioned in section 26(1) were set
out in Regulations 9 and 10 of the Personal Data Protection Regulations 2014 (which were
in force at the time) (the “Transfer Regulations 2014”). The Transfer Regulations 2014 was
recently amended (“the Transfer Regulations 2021”). The ensuing analysis and application
of the Transfer Regulations 2014 is equally relevant for the Transfer Regulations 2021, which
is in pari materia but for some re-numbering of the regulations.

The Transfer Regulations 2014 provides for a range of transfer mechanisms to ensure

compliance with Section 26(1) of the PDPA, e.g. through legally enforceable obligations under
any law, contracts, binding corporate rules or any other legally binding instruments. Within a
group of companies, reliance on intra-group agreements and binding corporate rules is common
for cross-border data transfers. They provide a flexible system for centralisation of corporate
functions and services. The commercial decision would be driven by where these functions are
best located, and intra-group agreements and binding corporate rules allow the group to
establish a bespoke internal governance system to ensure that personal data is well managed

across the group. The Transfer Regulations 2014 (and 2021) support the adoption of intragroup agreements and binding corporate rules in the following manner.

Pursuant to Regulation 9(1)(b), the Organisations could have met the Transfer

Limitation Obligation by taking appropriate steps to ensure that the recipients of the transferred
personal data in United Kingdom and Malaysia were bound by legally enforceable obligations
(in accordance with Regulation 10(1) of the Transfer Regulations 2014) to provide to the
transferred personal data a standard of protection that is at least comparable to that under the
PDPA. Regulation 9(1)(b) is now Regulation 10(1) in the Transfer Regulations 2021.
Regulation 10(1) of the Transfer Regulations 2014 specifies that such legally enforceable
obligations includes any law, a contract that complies with the conditions in Regulation 10(2),
or binding corporate rules that meets the conditions set out in Regulation 10(3). These same
regulations are now in Regulation 11 in the Transfer Regulations 2021. These regulations
support the use of intra-group agreements1 and binding corporate rules2.

Investigations revealed that the Organisations did not put in place intra-group

agreements, binding corporate rules or any other legally binding instrument to ensure that a
standard of protection comparable to the PDPA is provided to personal data transferred within
the group as required by Regulation 10(1).

In its responses to the Commission, the Organisations put forward the argument that

they had met the Transfer Limitation Obligation under the PDPA by virtue of the fact that the
laws of the United Kingdom applied to the receiving organisations within their group. I do not
exclude the possibility that the data protection system that governs the receiving organisation

1
2

See Re Everlast Projects & Others [2020] SGPDPC 20 at [13].
See Re Singapore Technologies Engineering Limited [2020] SGPDPC 21.

may, on a proper analysis, provide comparable protection. However, based on the responses
made by the Organisations to the Commission, I am not satisfied that the transferring
organisation conducted this analysis and concluded that there would be comparable protection
before the transfer. After the fact justification will not be accepted.

Of the 1,083 Singapore-based individuals whose personal data had been transferred to

the ultimate parent company in the United Kingdom, the Organisations mentioned that 44 of
these individuals, who were employees, had consented to the transfer of their personal data out
of Singapore in their employment contracts. Regulation 9(3)(a) of the Transfer Regulations
2014 did provide for the Transfer Limitation Obligation to be met by obtaining the consent of
individuals for the transfer of their data. However, to meet the consent requirement under
Regulation 9(3)(a) of the Transfer Regulations 2014, Regulation 9(4) requires the
Organisations to provide to the individuals a summary in writing of the extent to which their
personal data, when transferred to a foreign country or territory, would be protected to a
standard comparable to the PDPA. These requirements are now encapsulated in Regulations
10(2)(a) and 10(3) of the Transfer Regulations 2021. The procedural safeguards established by
Regulation 9(3) of the Transfer Regulations 2014 makes the use of consent somewhat more
cumbersome, as there is a need for consent to be refreshed whenever reorganisation of the
group’s internal function leads to a relocation of that function in a different jurisdiction. This
also does not enable the Organisations to benefit from the employment management exception
to the requirement for consent. Be that as it may, this option is available for organisations that
choose to rely on it. However on the evidence, this summary in writing was not provided by
the Organisations to the 44 Singapore employees.

The Deputy Commissioner’s Directions

In view of the foregoing, I therefore find that the Organisations have failed to discharge

their Transfer Limitation Obligation under section 26 of the PDPA. The Organisations are
directed to do the following within 30 days from the date of this Decision:

(a) put in place intra-group agreements or binding corporate rules for compliance with
section 26 of the PDPA in relation to any personal data transferred out of
Singapore3;
(b) if relying on consent, review and make necessary changes to its consent and
notification processes for compliance with section 26 of the PDPA and Regulation
10(3) of the Personal Data Protection Regulations 2021 in relation to any personal
data transferred out of Singapore; and
(c) inform the Commission of the completion of the above within 7 days of
implementation.

YEONG ZEE KIN
DEPUTY COMMISSIONER
FOR PERSONAL DATA PROTECTION

Refer to Regulation 11 of Personal Data Protection Regulations 2021, which is applicable at the present time.

",Directions,3b598c8a7be71e58fadf5f81e6bf2476ad13c791
57,57,1,952,Singapore Telecommunications Limited was found not in breach of the PDPA in relation to an incident which occurred on or about 13 July 2020 where a threat actor accessed the accounts belonging to 17 subscribers.,"[""Not in Breach"", ""Information and Communications"", ""Phishing""]",2021-08-12,https://www.pdpc.gov.sg/-/media/Files/PDPC/PDF-Files/Commissions-Decisions/Decision---Singapore-Telecommunications-Limited---21062021.pdf,,No Breach of the Protection Obligation by Singapore Telecommunications Limited,https://www.pdpc.gov.sg/all-commissions-decisions/2021/08/no-breach-of-the-protection-obligation-by-singapore-telecommunications-limited,2021-08-12,"PERSONAL DATA PROTECTION COMMISSION
Case No. DP-2007-B6607

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

Singapore Telecommunications Limited

SUMMARY OF THE DECISION
1.

On 15 July 2020, Singapore Telecommunications Limited (the “Organisation”)
informed the Personal Data Protection Commission of an incident which had
occurred on or about 13 July 2020 (the “Incident”). In the Incident, a threat actor
accessed the accounts of 17 of the Organisation’s telecommunications service
subscribers to request for issuance of new SIM cards, forwarding of voice calls
and/or cessation of mobile services 1 . Once these were issued, the affected
subscribers were unable to access to their own accounts.

The Organisation investigations indicated that the Incident was due to threat
actor(s) who gained access to its IT systems through coordinated social
engineering tactics targeted at staff. The threat actor(s)’ aim was to use
compromised staff accounts to gain control of subscriber accounts of the affected
individuals to perform unauthorised activities.

The Organisation also made reports to IMDA under the Telecoms Act and the
Singapore Police Force (“SPF”).

The Organisation’s investigations found no evidence that the integrity of its
affected IT systems had been compromised or that any data had been exfiltrated
from the systems at the time of the Incident, the Organisation had in place
reasonable security arrangements that included the following:
a. Password requirements in security policies, standards and guidelines were
aligned to industry best practices;

Singtel stated that the threat actor could have also accessed the records of an additional 15 subscribers.

b. Systems and network enhancements were continually implemented to
improve the security of applications and IT infrastructure;
c. Comprehensive and annual mandatory training was conducted for all staff in
relation to the requirements under the PDPA; and
d. Reasonable security measures were in place for the work environment of all
staffs based locally and overseas.
5.

The Organisation took prompt action to mitigate the effects of the breach by
suspending the compromised staff accounts and by password resets. Apart from
exclusion from their account for a limited duration, no other loss or damage to
any individual was reported from the Incident. Remedial action to prevent
recurrence will remain confidential for security reasons.

The Deputy Commissioner for Personal Data Protection found that the
Organisation had met its Protection Obligation in the circumstances. No
enforcement action therefore needs to be taken in relation to the Incident.

",Not in Breach,01a5079b89086159131ed4e343c0e882d01a1e85
58,58,1,952,"A financial penalty of $7,000 was imposed on Larsen & Toubro Infotech for failing to put in place reasonable security arrangements to prevent the unauthorised disclosure of personal data of job applicants, and for disclosing the personal data of job applicants without their consent.","[""Protection"", ""Consent"", ""Financial Penalty"", ""Information and Communications"", ""Protection"", ""Consent"", ""Sample forms"", ""Email"", ""Recruitment""]",2021-06-10,https://www.pdpc.gov.sg/-/media/Files/PDPC/PDF-Files/Commissions-Decisions/Decision--Larsen--Toubro-Infotech-Limited-Singapore-Branch-06052021.pdf,"Protection, Consent",Breach of the Protection and Consent Obligation by Larsen & Toubro Infotech,https://www.pdpc.gov.sg/all-commissions-decisions/2021/06/breach-of-the-protection-and-consent-obligation-by-larsen-toubro-infotech,2021-06-10,"PERSONAL DATA PROTECTION COMMISSION
Case No. DP-2011-B7464
In the matter of an investigation under section 50(1) of the
Personal Data Protection Act 2012
And
Larsen & Toubro Infotech Limited, Singapore Branch

SUMMARY OF THE DECISION
1. On 29 November 2020, the Personal Data Protection Commission (the “Commission”)
received a complaint against Larsen & Toubro Infotech Limited, Singapore Branch
(“LTI”) from an LTI job applicant.

2. On 25 November 2020, an LTI employee had emailed the complainant a set of sample
forms which contained the personal data of a past job applicant. The LTI employee had
sent the complainant those sample forms to assist him in filling up his own forms correctly.

3. Subsequently, on 3 December 2020, another LTI employee sent an email reminder to the
complainant and 53 other job applicants to complete their application process. The email
contained all of the job applicants’ respective names, with their email addresses placed in
the “To” field and thus visible to all recipients.

4. Once notified of the complaint by the Commission, LTI undertook a review of its
employees’ emails for the period from 2016 to 2020, and uncovered 73 other instances
where past job applicants’ personal data had been disclosed to other job applicants.

5. In total, 13 past job applicants’ forms were disclosed by 10 of LTI’s employees to 74 other
job applicants. The personal data disclosed in the forms comprised:

a. Name;
b. Signature;
c. Email address;
d. National Identification/ passport numbers;
e. Date of Birth;
f. Address;
g. Contact number;
h. Medical health status;
i. Employment history;
j. Salary information; and
k. Criminal records disclosure.

6. The Deputy Commissioner for Personal Data Protection finds that LTI negligently
contravened the Protection Obligation under section 24 of the Personal Data Protection Act
2012 by failing to provide adequate instructions to its employees dealing with recruitment
matters on how to handle personal data. LTI also negligently contravened the Consent

Obligation under section 13 of the Personal Data Protection Act 2012, by disclosing the
names and email addresses of all job applicants in its email sent to the 54 job applicants on
3 December 2020, including the complainant.

7. While LTI claimed to have a general Corporate Privacy Policy and an Employee Privacy
Notice which applied to all employees, the purpose of these documents was to provide
notice to individuals and employees on how LTI used, processed, and protected personal
data. Guidance to employees on how they should handle personal data in the course of work
could only be found in LTI’s “Data Privacy Awareness” training materials. LTI had no
targeted policies or standard operating procedures specifically for the employees handling
recruitment matters, despite the type and volume of personal data handled by such
employees. The fact that as many as 10 of LTI’s employees had engaged in the same
conduct over a 4 year period, reinforced the finding that the existing instructions were
inadequate.

8. LTI indicated that it would make all its employees aware of this incident, and that it would
implement a new set of procedures for email communications to external job applicants.
LTI notified all affected job applicants of the wrongful disclosure of their personal data to
other job applicants, and informed the job applicants to delete the emails they had received
containing the affected job applicants’ forms. Refresher training was also conducted for the
employees who had sent the emails.

9. After considering the circumstances of the case and the factors listed at section 48J(6) of
the Personal Data Protection Act 2012, including LTI’s cooperation with investigations, its
proactive review to identify additional historical breaches, and its prompt remedial actions,
the Deputy Commissioner for Personal Data Protection requires that LTI pay a financial
penalty of $7,000 for the breach.

10. LTI must make payment of the financial penalty within 30 days from the date of this
decision, 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 the financial
penalty until it is paid in full.

11. No further directions are required as LTI had taken actions to address the gaps in its security
arrangements.

",Financial Penalty,bd9f440070a5521214d61291f17b40de724a111a
59,59,1,952,"A financial penalty of $25,000 was imposed on Webcada for breaches of the PDPA. First, the organisation failed to put in place reasonable measures to protect personal data on its database servers. Second, it did not have written policies and practices necessary to ensure its compliance with the PDPA.","[""Protection"", ""Accountability"", ""Financial Penalty"", ""Information and Communications"", ""Ransomware"", ""IPMI"", ""Database servers"", ""No Written Policy""]",2021-06-10,https://www.pdpc.gov.sg/-/media/Files/PDPC/PDF-Files/Commissions-Decisions/Decision---Webcada-Pte-Ltd-06052021.pdf,"Protection, Accountability",Breach of the Protection and Accountability Obligation by Webcada,https://www.pdpc.gov.sg/all-commissions-decisions/2021/06/breach-of-the-protection-and-accountability-obligation-by-webcada,2021-06-10,"PERSONAL DATA PROTECTION COMMISSION
Case No. DP-2009-B6931
In the matter of an investigation under section 50(1) of the
Personal Data Protection Act 2012
And
Webcada Pte Ltd

SUMMARY OF THE DECISION
1. On 4 September 2020, Webcada Pte Ltd (the “Organisation”) notified the Personal Data
Protection Commission (the “Commission”) that three of its database servers had been
subjected to a ransomware attack on 29 August 2020 (the “Incident”).

2. The personal data of 522,722 individuals were affected in the Incident. The datasets
affected comprised of the individuals’ names, phone numbers, dates of birth, addresses and
order histories.

3. Following the Incident, the Organisation engaged an independent third-party consultant to
investigate, review and assist in the implementation of additional data protection measures.

4. Investigations revealed that the ransomware had been uploaded onto the affected servers
via the Intelligent Platform Management Interface (""IPMI""). The IPMI is a set of computer

interface specifications used for remote monitoring and management of servers. There was
no evidence of data exfiltration, and all affected data was restored from available back-ups.

5. The Organisation took the following remedial measures after the Incident:
(a) IPMI was permanently disabled for all servers;
(b) The public IP address of all servers was removed and all remote management access to
the servers was configured to allow only trusted IP addresses;
(c) End-point protection software with threat hunting capabilities was installed on all
servers and computers within the Organisation; and
(d) A written data protection policy was developed and implemented to comply with the
provisions of the Personal Data Protection Act 2012 (the ""PDPA"").

6. In its representations to the PDPC, the Organisation admitted to having breached the
Accountability Obligation under section 12 and the Protection Obligation under section 24
of the PDPA, and requested for the matter to be dealt with in accordance with the PDPC’s
Expedited Decision Procedure.

Section 12 of the PDPA
7. First, the Organisation admitted it did not have a written data protection policy prior to the
Incident. In this regard, it is important to reiterate that an organisation must document its
data protection policies and practices in writing as they serve to increase awareness and

ensure accountability of the organisation's obligations under the PDPA. This requirement
has been emphasized multiple times in previous decisions1.

Section 24 of the PDPA
8. Second, the Organisation admitted that it did not configure its IPMI access settings
correctly prior to the Incident. It enabled access to the IPMI from the public Internet when
this was not necessary. Furthermore, in the monthly vulnerability scans carried out by the
Organisation, it had omitted to scan the IPMI. Hence, it was not able to detect
vulnerabilities in its IPMI, which were exploited to gain access to and upload the
ransomware on the servers.

9. In the circumstances, the Organisation is found to have breached sections 12 and 24 of the
PDPA.

10. After considering the factors listed at section 48J(6) of the PDPA and the circumstances
of this case, including (i) the Organisation's upfront voluntary admission of liability which
significantly reduced the time and resources required for investigations; and (ii) the
Organisation's prompt remedial actions, the Organisation is given notice to pay a financial
penalty of $25,000.

See Re Aviva Ltd [2017] SGPDC 14 at [32]; Re Singapore Taekwondo Federation [2018] SGPDC 17 at [39] to
[42]; Re AgcDesign Pte Ltd [2019] SGPDC 23 at [4] to [5]; Re (1)Everlast Projects Pte Ltd (2)Everlast
Industries (S) Pte Ltd (3) ELG Specialist Pte Ltd [2020] SGPDC 20 at [8] to [9]

11. The Organisation must make payment of the financial penalty within 30 days from the date
of the notice accompanying this decision, 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.

12. In view of the remedial actions taken by the Organisation, the Commission will not issue
any directions under section 48I of the PDPA.

",Financial Penalty,a8330d4666d7631b3e448330fd698843754474f4
60,60,1,952,"A financial penalty of $35,000 was imposed on HMI Institute for failing to put in place reasonable security arrangements to protect personal data stored in its server. This resulted in the data being subjected to a ransomware attack.","[""Protection"", ""Financial Penalty"", ""Education"", ""Ransomware"", ""Third Party Vendor"", ""Scope of Duties"", ""Open RDP Port"", ""Remote Desktop Protocol""]",2021-06-10,https://www.pdpc.gov.sg/-/media/Files/PDPC/PDF-Files/Commissions-Decisions/Decision---HMI-Institute-of-Health-Sciences---20052021.pdf,Protection,Breach of the Protection Obligation by HMI Institute of Health Sciences,https://www.pdpc.gov.sg/all-commissions-decisions/2021/06/breach-of-the-protection-obligation-by-hmi-institute-of-health-sciences,2021-06-10,"PERSONAL DATA PROTECTION COMMISSION

[2021] SGPDPC 4

Cases No DP-1912-B5434 / DP-1912-B5564 / DP-1912-B5558

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

And

HMI Institute of Health Sciences Pte. Ltd.
… Organisation

DECISION

HMI Institute of Health Sciences Pte. Ltd.
[2021] SGPDPC 4
Lew Chuen Hong, Commissioner — Cases No. DP-1912-B5434 / DP-1912-B5564 /
DP-1912-B5558
20 May 2021
Introduction
1

On 4 December 2019, a file server (the “Server”) belonging to HMI Institute of

Health Sciences Pte. Ltd. (the “Organisation”) was affected by a ransomware attack.
The ransomware encrypted and denied access to various files on the Server, including
files containing personal data of the Organisation’s staff and trainees (the “Incident”).
2

On 7 December 2019, the Organisation informed the Personal Data Protection

Commission (“Commission”) of the Incident. The Commission subsequently received
two separate complaints about the Incident.
Background
3

The Organisation is a dedicated private provider of healthcare training to

individuals (“Participants”) in Singapore. In the course of carrying out its business
activities, the Organisation collects personal data from, among others, (i) its
employees, including temporary and contract staff such as associate trainers,
(“Employees”) for the purposes of managing or terminating such employment
relationships, and (ii) the Participants, for the purposes of registration and the
administration of their enrolment in the Organisation’s training courses.
4

The Server affected by ransomware was set up in 2014 and was located in

Singapore. It was owned by the Organisation but maintained by the Organisation’s
appointed IT solution service provider (the “Vendor”). The Server stored personal data
in Microsoft Word or Excel files, most but not all of which were password-protected.
5

The Server was protected by a firewall that blocked all connections to the

Server, except for those through port 3389, a standard port which was used for the
Remote Desktop Protocol (“RDP Port”). The RDP Port was used by the Vendor for

remote management and/or troubleshooting purposes. According to the Organisation,
the RDP Port was kept open from sometime in 2014 up to the date of the Incident on
4 December 2019 (i.e. for more than four (4) years) to allow the Vendor quick and
easy access. The significance of the RDP Port being kept open will be elaborated on
below.
6

The Server only had one administrator account which was shared by the

Organisation’s IT administrator and at least three other employees of the Vendor. By
use of this administrator account, the Vendor could access the Server remotely
through the RDP Port and view, change, or delete all the data in the Server.
7

On 4 December 2019, an employee of the Organisation was unable to access

files on the Server containing the personal data of some Participants. An initial
diagnostic conducted by the Vendor revealed that the Server had been affected by
ransomware. File extensions of the files on the Server had been changed and a
ransom note was found on the Server.
8

On 5 December 2019, the Organisation engaged a cybersecurity expert

company (“CSE”) to conduct a thorough assessment of the Incident. The CSE found
that:
(a)

the attacker had likely discovered the open RDP Port following a

random, opportunistic search for vulnerabilities; and;
(b)

having discovered the open RDP Port, it was likely that the attacker

used brute force attacks to obtain the administrator account password for the
Server in order to gain access to the Server and execute the ransomware.
9

In total, the personal data of approximately 110,080 Participants, and 253

Employees were affected by the Incident (the “Affected Personal Data”).
10

For the affected Participants, the following categories of personal data were

affected:
(a)

Name;

(b)

NRIC number;

(c)

Address;

(d)

Race;

(e)

Gender;

(f)

Date of Birth;

(g)

Age;

(h)

Email address;

(i)

Contact number;

(j)

Course details;

(k)

Nationality; and

(l)

Employer details and past employment history.

For the affected Employees, the following categories of personal data were

affected:
(a)

Name;

(b)

NRIC number;

(c)

Date of Birth;

(d)

Nationality;

(e)

Citizenship;

(f)

Age;

(g)

Contact number;

(h)

Vehicle licence plate; and

(i)

Financial Information (including salary/payment information, Central

Provident Fund (“CPF”) information, and bank account numbers.
12

Not all of the above categories of personal data were affected in every

individual’s case. For instance, the bulk of the affected Participants (approximately
98,000) only had their names and NRIC numbers stored on the Server.
13

The CSE’s investigation found no evidence of any exfiltration of the Affected

Personal Data from the Server. The Organisation also managed to retrieve all the
Affected Personal Data as most of the affected files were back-up files.
14

Upon being made aware of the Incident, the Organisation took prompt remedial

actions. The Organisation:
(a)

Decommissioned the Server (without paying the ransom), and isolated

the Server from its network and the Internet;
(b)

Notified the Commission, SingCERT, and all the affected Employees

and Participants that it was able to (approximately 95%) of the Incident; and
(c)
15

Issued a media advisory on the Incident.

The Organisation also carried out actions to prevent a recurrence of the

Incident. It:
(a)

Adopted its own internal password management policy;

(b)

Permanently disconnected and blocked remote access for IT support

procedures;
(c)

Implemented Internet separation measures for all devices containing

personal data;
(d)

Introduced various endpoint enhancements and gateway security

measures including a monitoring system for all Internet-facing traffic, a suite of
antivirus and malware protection for all computers and enhancing email hosting
security protection and hard disk encryption;

(e)

Engaged external IT security consultants to establish an Information

Security Management Framework based on the ISO 27001 certification;
(f)

Conducted cybersecurity training sessions and cybersecurity awareness

workshops for its staff;
(g)

Conducted ad-hoc email phishing tests to augment the cybersecurity

training sessions and to engender greater awareness and vigilance towards
suspicious emails; and
(h)

Put in place a monthly IT bulletin post to all employees to keep all staff

up to date on IT and cybersecurity issues.
Findings and Basis for Determination
Whether the Organisation had contravened section 24 of the PDPA
16

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

As a preliminary point, even though the Organisation had engaged the Vendor

to maintain the Server and the Organisation’s other IT infrastructure, the scope of the
Vendor’s engagement did not involve the processing or handling of any personal data
on behalf of the Organisation. The Organisation owned the Server and was in
possession and control of the Affected Personal Data at all material times. The Vendor
was therefore not a data intermediary and the responsibility to protect the Affected
Personal Data fell squarely on the Organisation.
18

For the reasons set out below, the Organisation failed to implement reasonable

security arrangements to protect the Affected Personal Data from the risk of authorised
access, modification and disposal.

Failure to adequately regulate remote access to the Server
19

First, the Organisation did not have sufficiently robust processes to ensure safe

remote access to the Server via the RDP Port. The Remote Desktop Protocol (i.e.,
RDP) is a proprietary protocol developed by Microsoft Corporation for use in its
Remote Desktop Connection application, which allows for remote connections to be
established from one computer (i.e., a server) to another computer (i.e., the client)
allowing the client to remotely control the server. By default, the server uses port
number 3389 (i.e., the RDP Port) for incoming connections and requires authentication
in the form of a username and password, before access to the server is granted. While
the RDP Port is intended to be used for legitimate RDP client-server connections, its
existence is well known and thus susceptible to be exploited by malicious actors to
gain unauthorised access to a server if there are weak protective measures in place
(e.g. weak user authentication).
20

While there is no strict requirement that the RDP Port must always be closed,

organisations should regularly review and assess the potential risks of keeping such
public facing ports open. Where it is necessary to keep the RDP Port on a server open,
organisations should ensure that there are sufficient measures in place to protect the
personal data stored on the server.
21

That said, where an organisation holds a high volume of personal data and/or

highly sensitive personal data, the Commission is of the view that the default approach
should be to close all ports, including RDP Ports. Where it is necessary to open the
RDP Port, organisations must ensure that there are sufficient measures in place to
ensure the security and legitimacy of any incoming RDP connection, and to promptly
close the RDP Port upon completion of the required use. Additional measures to
secure the files, for example, access control to folders and file encryption, may also
be deployed. These are different layers of defences that can be used cumulatively or
in different combination, depending on the volume and sensitivity of personal data and
the requirements of business operations.
22

In this case, the Organisation kept the RDP Port open from the time the Server

was set up in 2014 until the occurrence of the Incident on 4 December 2019. According

to the Organisation, the RDP Port was kept open to allow the Vendor quick remote
access to the Server for recovery and maintenance works. The Organisation claimed
that keeping the RDP Port permanently closed was not practicable, as half a day of
down time would be required whenever the RDP Port needed to be opened or closed.
23

Given the fact that a minority of records (i.e. 253 Employees) contained more

sensitive financial information and bank account numbers, as well as the volume of
personal data stored on the Server, it is questionable whether the RDP Port should
have been kept open permanently for recovery or maintenance work. Even if this
meant incurring some down time in activating and deactivating the firewall for the RDP
Port, the inconvenience associated with this down time should have been measured
against the risk to the type and volume of personal data that was stored on the Server.
Nonetheless, the benefit of doubt is given to the Organisation as the majority of records
were personal particulars and contact information.
24

Even if it was necessary for the RDP Port to be kept open, the Organisation

should at least have put in place other types of technical measures to secure the RDP
access, such as:
(a)

Using a different port (other than the default port 3389) for RDP

connections;
(b)

Restricting access to specific IP addresses or IP addresses within

specified ranges, i.e. “whitelisting”;
(c)

using a RDP gateway; and/or

(d)

Conducting log reviews for unusual activity, whether upon automated

alerts or scheduled monitoring.
25

The risks arising from poor management of RDP Ports have also been

highlighted in the Cyber Security Agency of Singapore’s (“CSA”) recent advisory dated
28 December 2020, titled “Protect Your Systems and Data From Ransomware
Attacks” 1 . The CSA similarly cautioned that some ransomware variants take

https://www.csa.gov.sg/singcert/advisories/ad-2020-006

advantage of exposed services and open ports such as the RDP Port to spread across
a network. As such, in order to minimise the chance of a ransomware attack, the CSA
emphasised that organisations should review their port settings, particularly, to assess
whether there was a need to leave the RDP Port exposed, and if so, to restrict RDP
connections to only trusted hosts.
26

The Organisation represented to the Commission that it would have been

impractical to whitelist specific IP addresses as connections to the Server were
generally made through dynamic, instead of static, IP addresses. Even so, the onus
remained on the Organisation to put in place alternative security measures that were
commensurate with the standard of protection required to protect sensitive data stored
on the Server. However, the Organisation failed to implement any such alternative
security measures.
27

The Organisation’s inaction on this front placed the Server at risk for more than

four years - from the time the Server was set up in 2014 until it was disconnected
from the Internet after the Incident.
Failure to implement proper password management
28

Second, the Organisation failed to implement proper password management

policies. The Organisation had adopted and generally directed its staff to follow the
password policy of one of its affiliates (the “Password Policy”). The guidelines and
standards in the Password Policy are consistent with the Commission’s
recommendations in its Guide to Securing Personal Data in Electronic Medium2, which
recommends that passwords used for authentication have a length of at least 8
characters, containing at least one alphabetical character and one numeric character.
29

However, the Organisation failed to take steps to ensure that the Password

Policy was compiled with in practice. None of the passwords used by the Organisation
for the administrator account of the Server or the files containing the Affected Personal
Data (including those containing financial information) met the Password Policy’s
recommended complexity rules. The passwords used by the Organisation also

https://www.pdpc.gov.sg/help-and-resources/2017/10/guide-to-securing-personal-data-in-electronic-medium

incorporated an acronym of the organisation’s name, which made them easy to guess
and vulnerable to brute force attacks.
30

As noted in Re Chizzle Pte Ltd [2020] SGPDPCR 1 at [5(d)]:
“In this regard, various articles/guides have stated that the use of an
organisation’s name as a component of the password is not
recommended because it is not difficult to guess and cracked by hackers.
The digits “2018” as a component of the password was also guessable,
for example, through brute force or dictionary attacks. As such, the
password used by the Organisation failed to prevent unauthorised copying
and deletion of the Chizzle Database.”
[Emphasis added]

The login credentials for the administrator account on the Server were also

shared between one administrator in the Organisation and at least three other
individuals in the Vendor. Other than the login credentials, there were no other access
controls to the administrator account (e.g.

2FA or anti-hammering features). As

previously stated in Re Orchard Turn Developments Pte Ltd [2017] SGPDPC 12 (at
[31]) user accounts should generally not be shared between different individuals, and
all the more so for administrator accounts:
“Additionally, there should not be a sharing of credentials amongst
users. When credentials are shared among multiple users, it is difficult
to ensure accountability as it is difficult to track the activity of each
individual using the common set of credentials.”
[Emphasis added]
32

Although the sharing of the administrator account credentials was not a direct

contributing factor to the Incident, the sharing of account credentials – in particular,
administrator accounts with high privileges – created an additional risk factor which
could have diminished the robustness of other security measures put in place by the
Organisation.
9

Similarly, while strong passwords may only slow but not entirely deter threat

actors, the absence of strong passwords could greatly facilitate unauthorised access
to IT systems, including IT systems holding personal data.
Failure to take reasonable steps to ensure that the Vendor would protect personal data
34

Thirdly, while the Organisation claims to have relied on the Vendor’s technical

expertise with regard to the security of the Server, the Organisation did not take
reasonable or sufficient steps to stipulate clear requirements of its Vendor to ensure
that the Vendor understood its role in the protection of the personal data in the Server.
35

As mentioned in the Commission’s Guide to Managing Data Intermediaries3:
“The primary means by which a DC (i.e. a Data Controller) may ensure
appropriate protection and retention of the personal data processed by its
DI (i.e. a Data Intermediary) is through a contract. As the range of data
processing activities that can potentially be outsourced is very broad, it is
necessary for the scope of outsourced data processing activities to be
clearly defined and agreed upon. There should be clear communication
between the DC and the DI on the scope of outsourced data processing
activities and the personal data requirements. For the DC, this is crucial in
ensuring that its business requirements and management decisions in
relation to the outsourcing are made clear to the DI.”

The Vendor in this case was not a Data Intermediary. However, the Vendor was

nevertheless expected to handle personal data in the course of its work or make
decisions which affected the security of personal data stored in the Server 4. As such,
in order for the Organisation to say that it had discharged its Protection Obligation by
relying on the Vendor’s technical expertise, clear business requirements on the
protection of the data in the Server should have been specified. Alternatively, the
Vendor could have made recommendations on the data protection requirements
based on its understanding of the engagement (including for protection of the data in
the Server), which the Organisation could have approved and adopted. In either case,
3
4

https://www.pdpc.gov.sg/Help-and-Resources/2020/09/Guide-to-Managing-Data-Intermediaries
See Civil Service Club [2020] SGPDPC 15 at [13] and [14]

reasonable efforts should have been taken by the Organisation to verify that the
Vendor was meeting its data protection requirements.
37

The exact requirements for a given case would depend on the services that a

vendor is engaged to provide. If a vendor is engaged to put in place protection features
for a Data Controller’s IT systems, the business requirements should describe the risks
that the vendor is to address. In this case, the Organisation’s contract with the Vendor
did not specify any business requirements for the protection of personal data in the
Server. Neither could the Organisation provide any evidence to suggest that the
Vendor made any recommendations about how to protect the data in the Server. As
such, the Organisation could not say that it had discharged its Protection Obligation
by relying on the expertise of the Vendor.
38

In the circumstances, the Commissioner finds that the Organisation failed to

make reasonable security arrangements to protect the personal data in the Server
from the risk of unauthorised access, modification and disposal. Accordingly, the
Commissioner finds the Organisation in breach of its obligation under section 24 of the
PDPA.
The Commissioner’s Directions
39

In determining whether any directions should be imposed on the Organisation

under section 48I of the PDPA, and/or whether the Organisation should be required to
pay a financial penalty under section 48J of the PDPA, the factors listed at section
48J(6) of the PDPA and the following aggravating and mitigating factors were taken
into account:
Aggravating Factor
(a)

the Organisation’s failure to put in place reasonable security measures

put the personal data in the Organisation’s possession and/or control at risk of
exposure for more than four years. The failure to protect led to the unauthorised
access and modification of the personal data in the Incident;

Mitigating Factors
(b)

the Organisation took prompt remedial actions following the Incident;

and
(c)
40

the Organisation was cooperative during the investigations.

Having considered all the relevant factors of this case, including

representations made by the Organisation on 1 April 2021 after being notified of the
Commissioner’s Preliminary Decision, the Commissioner hereby directs the
Organisation to pay a financial penalty of $35,000 within 30 days from the date of the
relevant notice, 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.
41

In view of the remedial actions that have already been taken by the

Organisation, no other directions are necessary.

YEONG ZEE KIN
DEPUTY COMMISSIONER
FOR COMMISSIONER FOR PERSONAL DATA PROTECTION

",Financial Penalty,65d2d1e1ed47bb4f1dba6c7af5b321b1ae19c7c3
61,61,1,952,"A financial penalty of $8,000 was imposed on ST Logistics for failing to put in place reasonable security arrangements to prevent the unauthorised access of 2,400 MINDEF and SAF personnel's personal data.","[""Protection"", ""Financial Penalty"", ""Transport and Storage"", ""Phishing"", ""Malware""]",2021-06-10,https://www.pdpc.gov.sg/-/media/Files/PDPC/PDF-Files/Commissions-Decisions/Decision---ST-Logistics-Pte-Ltd---26102020.pdf,Protection,Breach of the Protection Obligation by ST Logistics,https://www.pdpc.gov.sg/all-commissions-decisions/2021/06/breach-of-the-protection-obligation-by-st-logistics,2021-06-10,"PERSONAL DATA PROTECTION COMMISSION

[2020] SGPDPC 19
Case Nos. DP-1912-B5514 and DP-1912-B5559

In the matter of an investigation under section 50(1)
of the Personal Data Protection Act 2012
And
ST Logistics Pte Ltd
… Organisation

DECISION

ST Logistics Pte Ltd
[2020] SGPDPC 19
Lew Chuen Hong, Commissioner — Case Nos. DP-1912-B5514 and DP1912-B5559

26 October 2020

Introduction
1

Phishing attacks are increasingly prevalent and are one of the top

cybersecurity threats faced by organisations1. In its latest report, the Cyber
Security Agency of Singapore reported 47,500 cases of phishing in Singapore
last year, almost triple the number of cases in 20182. This case is yet another
example of an organisation falling victim to phishing.
2

On 16 December 2019, ST Logistics Pte Ltd (the “Organisation”)

notified the Personal Data Protection Commission (the “Commission”) that the
Organisation had detected an Emoted malware (“Emotet”) in their network
which had infected 6 of its users’ laptops (including 4 laptops containing
personal data), potentially affecting up to 4,000 individuals in the Ministry of

1 Phishing is a method employed by cyber criminals, often disguising themselves as legitimate

individuals or reputable organisations, to fraudulently obtain personal data and other sensitive
or confidential information. Once cyber criminals obtain an individual’s personal data, they may
gain access to the individual’s online accounts and may impersonate the individual to scam
persons known to the individual. See Cyber Security Agency of Singapore, Cyber Tip – Spot
Signs of Phishing (25 February 2020) https://www.csa.gov.sg/gosafeonline/go-safe-forme/homeinternetusers/spot-signs-of-phishing.
2 See “Phishing attacks last year tripled from 2018”, The Straits Times, 27 June 2020.

ST Logistics Pte Ltd

[2020] SGPDPC 19

Defence (“MINDEF”) and Singapore Armed Forces (“SAF”) (the “Incident”).
Subsequently, on 23 December 2019, the Commission received a complaint
from an individual affected by the Incident.
Facts of the Case
3

The

Organisation

provides logistical

services to Singapore’s

government and defence sectors, as well as commercial sectors. It has more than
800 employees worldwide and an annual revenue of approximately S$350
million3.
4

On 2 October 2019, the Organisation’s users received phishing emails

from email addresses with the text “Stlogs” in the sender name field (e.g.
“Account Executive (Stlogs)” and “Assistant General Manager (Stlogs)”). Each
email contained an attachment with the file extension “doc”. A total of 13 users
from the Organisation opened the malicious attachment (the “Affected Users”).
7 Affected Users had the Palo Alto Traps software (“Traps Software”), an
advanced endpoint protection solution, installed in their laptops and were
therefore protected from Emotet. The remaining 6 Affected Users (“Infected
Users”) did not have Traps Software installed in their laptops. This resulted in
the Incident with Emotet being installed and executed on the laptops of the
Infected Users. Emotet subsequently harvested the emails in the Infected Users’
accounts, created approximately 100 new phishing emails, and sent these new
phishing emails on 3 October 2019. Those new phishing emails quoted the
bodies of real emails in the email accounts of the Infected Users.
5

Unencrypted files containing personal data were stored in 4 of the

Infected Users’ laptops. The files were offline working copy files used in
relation to the logistics services provided by the Organisation to the MINDEF

3 <https://www.stlogs.com/our company/about-st-logistics>.

ST Logistics Pte Ltd

[2020] SGPDPC 19

and SAF. The working files contained personal data relating to a total of 2,400
MINDEF and SAF personnel (“Affected Individuals”). The types of personal
data of the Affected Individuals at risk of unauthorised access (collectively, the
“Disclosed Data”) were:
(a)

Names;

(b)

Mailing addresses;

(c)

Email addresses;

(d)

Telephone numbers; and

(e)

NRIC numbers (1,320 full NRIC numbers and 1,080 masked

(last 3 digits and checksum) NRIC numbers).
6

Based on the Organisation’s investigations (including anti-virus scans

performed following the Incident), the infection by Emotet was limited to the
laptops of the Infected Users. At the time of the Incident, the Organisation’s
proxy logs captured information which showed that some exfiltration had taken
place. However, there was insufficient information in the proxy logs to confirm
that the exfiltration included files containing the Disclosed Data.
7

Upon discovery of the Incident, the following remedial actions were

taken to mitigate the effects of the Incident:
(a)

The Organisation immediately disconnected the Infected Users

laptops from the Organisation’s corporate network;
(b)

Security advisories (including guidelines on how to identify

phishing emails) were sent to all the Organisation’s users to inform them
of the Incident and to be vigilant; and

ST Logistics Pte Ltd

(c)

[2020] SGPDPC 19

All Affected Individuals were notified by MINDEF through text

messages by 27 December 2019.
8

In addition, the following remedial actions have been taken, or are

committed to be taken, by the Organisation to prevent recurrence of the Incident
or similar incidents.
(a)

The Organisation conducted a “PDPA awareness” programme in

February 2020 for its staff. “PDPA awareness” training materials were
made available to all staff on the Organisation’s intranet. Selected users
also attended the PDPA training offered by NTUC Learning Hub in
February 2020;
(b)

Malicious email domains were identified. Enhanced firewall

protection was implemented to inspect traffic to the Organisation’s
email gateway. Email rules were created to block similar phishing
emails from reaching the Organisation’s users;
(c)

The Organisation performed a company-wide validation

exercise to ensure that Traps Software was installed on the laptops of all
its users;
(d)

The Organisation conducted a Sender Policy Framework

verification to reduce the number of spam and phishing emails reaching
its users;
(e)

The Organisation implemented the display of warning banners

for emails that do not originate from the Organisation’s email server;
(f)

The Organisation will increase the frequency of sending

“Cybersecurity Advisory & Personal Data Protection Awareness”
notices to all users;

ST Logistics Pte Ltd

(g)

[2020] SGPDPC 19

The Organisation implemented internet separation via URL

filtering and has been exploring a sandbox feature and URL checking
for all emails;
(h)

Periodic phishing exercises will be conducted as part of the

Organisation’s Cybersecurity Awareness Program; and
(i)

Independent security experts will be engaged to perform

compromise assessment to validate the security status of the
Organisation’s systems environment in the third quarter of 2020.
The Commissioner’s Findings and Basis for Determination
9

Most phishing attacks are sent by email,4 and the most common form is

the general, mass-mailed type, where the cyber attacker sends an email
pretending to be someone else and tries to trick the email recipient to log into a
website or download malware.5 Based on the Commission’s past investigations,
there are generally 2 scenarios when a data breach involves phishing attacks on
e-mail accounts:
(a)

First, where malware harvests email addresses from the victim’s

email address book to send further phishing emails to contacts of the
victim. In this scenario, the only personal data that are accessed and used
by the malicious actor are email addresses; and

https://www.cisco.com/c/en_sg/products/security/email-security/what-is-phishing.html; See
also National Cyber Security Centre (United Kingdom), Phishing attacks: defending your
organisation (version 1.1, 8 August 2019) https://www.ncsc.gov.uk/guidance/phishing:
Phishing can be conducted via a text message, social media, or by phone, but the term 'phishing'
is mainly used to describe attacks that arrive by email.
5 https://www.csoonline.com/article/3234716/types-of-phishing-attacks-and-how-to-identify-

them.html

ST Logistics Pte Ltd

(b)

[2020] SGPDPC 19

Second, where the content of the victim’s email account is

compromised, and emails are downloaded and/or forwarded by
malicious actors. In this scenario, there may be personal data within the
body of the email message (e.g. customer information, employee human
resource data, payroll information etc.) as part of its communication
content. Some of these may be confidential or commercially sensitive
information.
10

The first type of email phishing attack at [9(a)] is more common, and

the risk of harm is relatively low as the unauthorised access and use is limited
to email addresses. Conversely, while the second type of email phishing attack
at [9(b)] is less common, the risk of harm is significantly greater. This is because
in addition to email addresses, communication content exposed to unauthorised
access and use may contain other type(s) of personal data (including those of a
sensitive nature, e.g. medical and financial data). Consequentially, a breach of
data protection obligations resulting in the organisation falling victim to the
second type of email phishing attack generally results in more serious
consequences.
11

The present case falls into the first type of email phishing attack, and the

issue for determination is whether the Organisation had complied with its
obligations under Section 24 of the Personal Data Protection Act 2012 (the
“PDPA”). 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 or similar risks (the “Protection Obligation”).
12

As a preliminary point, it is not disputed that the Organisation was in

possession and control of the Disclosed Data at all material times, and was
obliged to put in place reasonable security arrangements to protect the Disclosed
Data.
6

ST Logistics Pte Ltd

[2020] SGPDPC 19

The Commission’s investigations revealed that the Organisation failed

to conduct periodic security reviews to detect vulnerabilities in its IT systems.
(a)

As stated in the Commission’s previous decisions, organisations

are expected to conduct periodic security reviews of its IT systems.6
Conducting regular information and communication technology
(“ICT”) security audits, scans and tests to detect vulnerabilities help
organisations to ensure that ICT security controls developed and
configured for the protection of personal data are properly
implemented7. The comprehensiveness of such security reviews should
be scoped based on the organisation’s assessment of its data protection
needs, and be conducted to a reasonable standard;
(b)

In the present case, a reasonably conducted security review

should have included (i) verifying complete installation and proper
configuration of the security software on all of the Organisation’s users’
laptops; and (ii) checking that the security software is updated;
(c)

The Organisation’s failure to conduct a security review to a

reasonable standard resulted in the following undetected security gaps
that led to the Incident8:
(i)

The anti-virus software installed on users’ laptops was

not updated because they had not been properly configured to
receive updates. This security gap affected all of the Infected
Users, whose laptops were not so configured. The investigations

6 See Re WTS Automotive Services Pte. Ltd. [2018] SGPDPC 26 at [18], Re Bud Cosmetics

[2019] SGPDPC 1 at [24] and Re Chizzle Pte. Ltd. [2019] SGPDPC 44 at [6] to [8].
7 Commission’s Guide to Securing Personal Data in Electronic Medium (revised 20 January

2017) at [6.1].
8 As an updated anti-virus software and Traps Software both offered protection against Emotet,

the Organisation could have chosen to take a phased approach to its security review.

ST Logistics Pte Ltd

[2020] SGPDPC 19

into the Incident revealed that if anti-virus software had been
updated, it would have been able to block and remove Emotet at
the material time; and
(ii)

Due to a rollout gap, the Traps Software was not installed

on the laptops of some Organisation’s users. In contrast with
signature-based anti-virus software (which is used to identify
“known” malware), Traps Software detects malware based on
their behaviour. This enables Traps Software to detect newly
released forms of malware (which signature-based anti-virus
software may potentially fail to detect) based on behavioural
analysis. As mentioned at [4], this security gap affected all of the
Infected Users, on whose laptops the Traps Software had not
been installed. Conversely, the laptops of the remaining 7
Affected Users (who had also opened the malicious attachment)
had Traps Software installed, and were accordingly protected
from Emotet.
14

Based on the Commission’s preliminary findings, it appeared that the

Organisation also did not conduct proper data protection training for its staff. In
particular, the Organisation had conceded during investigations that not all the
Affected Users had completed the relevant data protection training at the time
the Incident occurred. The failure to conduct proper data protection training
would have been an additional ground (other than the omission to conduct
periodic security reviews to detect vulnerabilities in the IT system) in support
of finding the Organisation in breach of the Protection Obligation.
15

However, the Organisation subsequently clarified in its representations

to the Commission’s preliminary findings that its data protection training for its
staff prior to the Incident included PDPA awareness programmes conducted in
March and April 2019 and bi-monthly staff induction programmes covering
8

ST Logistics Pte Ltd

[2020] SGPDPC 19

cybersecurity and PDPA compliance. In addition, the training material for the
PDPA awareness programme, as well as relevant reference materials and the
URL link to the Commission’s website were provided in the Organisation’s
intranet to allow staff ready access to data protection related resources.
16

The Commission recognises that staff movement will always have to be

factored into staff training programmes, and at any one point in time, there will
always be members of staff at different stages of training. Having a training
programme in place and a system to track staff training is therefore important.
Thus, while not all the Affected Users had completed the relevant data
protection training at the time of the Incident, the arrangements the Organisation
had implemented towards trainings its staff on data protection was reasonable
in the circumstances.
17

For the reasons set out at [13] above, the Commissioner finds the

Organisation in breach of section 24 of the PDPA.
18

In addition to the representations made on data protection training, the

Organisation also raised the following factors for consideration in support of a
reduction in the quantum of financial penalty which the Commissioner intended
to impose:
(a)

The Organisation had put in place reasonable security

arrangements to protect the Disclosed Data prior to the Incident. These
included advanced end point solution (Palo Alto Traps) on corporate
servers and workstations; privileged access management; monitoring of
security events through security information and events management
systems; and web penetration test performed for corporate applications
by CREST accredited vendor. Notwithstanding these arrangements, the
Organisation was a victim of a phishing attack; and

ST Logistics Pte Ltd

(b)

[2020] SGPDPC 19

There was a low risk of harm arising from the Incident as the

unauthorised access and use of the Disclosed Data by the cyber attacker
were limited to email addresses. There was also no evidence that any
Disclosed Data had been exfiltrated.
19

The Organisation’s representations that it had put in place reasonable

security arrangements to protect the Disclosed Data prior to the Incident is not
accepted. As explained at [13], the Organisation failed to conduct periodic
security reviews to detect vulnerabilities in its IT systems. The requirement for
organisations to conduct periodic security reviews to comply has been
emphasised in the Commission’s previous decisions.9 Separately, the
Organisation’s representation that there was a low risk of harm arising from the
Incident is accepted and has been taken into account in determining the financial
penalty.
20

Having carefully considered the representations, the Commissioner has

decided to reduce the financial penalty to the amount set out at [22]. The
quantum of financial penalty has been determined after due consideration of the
low risk of harm arising from the Incident and the mitigating factors set out at
[21].
The Commissioner’s Directions
21

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

under Section 29 of the PDPA, the Commissioner took into account the
Organisation’s cooperation with the investigations and its prompt and
forthcoming responses to the Commission’s queries.

9 See cases listed at Footnote 6.

ST Logistics Pte Ltd

[2020] SGPDPC 19

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

directs the Organisation to pay a financial penalty of S$8,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 the financial penalty until it is paid in full. The
Commissioner has not set out any further directions given the remediation
measures already put in place.

YEONG ZEE KIN
DEPUTY COMMISSIONER
FOR COMMISSIONER FOR PERSONAL DATA PROTECTION

",Financial Penalty,50724d913acafbfd43b21653cd18c545ba471871
62,62,1,952,A warning was issued to Greatearth Corporation for failing to obtain consent to disclose personal data of 8 crane operators on the external façade of a construction site.,"[""Consent"", ""Warning"", ""Construction"", ""Consent"", ""Ban list"", ""Acting in Course of Employment""]",2021-05-12,https://www.pdpc.gov.sg/-/media/Files/PDPC/PDF-Files/Commissions-Decisions/Decision---Progressive-Builders-and-Greatearth-Corporation---16042021-(002).pdf,Consent,"Breach of the Consent Obligation by Greatearth Corporation, No Breach of the PDPA by Progressive Builders",https://www.pdpc.gov.sg/all-commissions-decisions/2021/05/breach-of-the-consent-obligation-by-greatearth-corporation,2021-05-12,"PERSONAL DATA PROTECTION COMMISSION

[2021] SGPDPC 2

Case No. DP-1907-B4305

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

And

(1) Progressive Builders
Private Limited
(2) Greatearth Corporation
Pte. Ltd.

… Organisation

DECISION

(1) Progressive Builders Private Limited; (2) Greatearth Corporation
Pte. Ltd.
[2021] SGPDPC 2

Yeong Zee Kin, Deputy Commissioner — Case No. DP-1907-B4305
16 April 2021
Introduction
1

This case involves a series of incidents that led to the unauthorised collection, use, and

disclosure of the personal data of 8 individuals (the “Complainants”) by Greatearth
Corporation Pte. Ltd. (“GCPL”). On 19 and 20 July 2019, the Personal Data Protection
Commission (the “Commission”) received complaints from each of the Complainants alleging
that their personal data had been disclosed by Progressive Builders Private Limited (“PBPL”)
without their consent (the “Complaints”). The Commission commenced an investigation into
the Complaints.
Facts of the Case
2

The Complainants are tower crane operators engaged by Craneworks Pte Ltd (“the

Subcontractor”) to operate tower cranes for the Subcontractor’s clients, including PBPL.
PBPL is the main contractor for a housing project in Geylang (the “Geylang Project”) and is
in charge of the Geylang Project worksite (the “Geylang Worksite”). PBPL had collected the
Complainants’ personal data (including their full name, NRIC, contact number and
photograph) when they were appointed as tower crane operators for the Geylang Project. The
collection of their personal data was for the purposes of managing the Complainants’ roles as
tower crane operators. The Subcontractor is a sub-contractor of PBPL for the Geylang Project.
It supplies licensed crane operators to PBPL for the operation of tower cranes.
3

GCPL is also a company that is in the construction business. It is the main contractor

for a housing project in Clementi (the “Clementi Project”) and is in charge of the Clementi

Project worksite (“Clementi Worksite”). GCPL does not have any business relationship with
PBPL, the Subcontractor, or the Complainants.
Creation of the Banned Operators List
4

Between 12 and 18 July 2019, a series of incidents involving the Complainants and the

staff of PBPL occurred at the Geylang Site. As a result of the incidents, PBPL banned the
Complainants from entering the Geylang Worksite. After the workplace incidents, PBPL’s
project director (“Project Director”) directed PBPL’s Workplace Safety & Health Officer
(“WSHO”) at the time to compile a list of the Complainants’ details, which included the
following personal data of each of the Complainants:
(a)

Full name;

(b)

NRIC number;

(c)

Contact number; and

(d)

Photo ID of the individual

(collectively, the “Banned Operators List”).
5

According to PBPL, the Banned Operators List was created to identify the

Complainants that were involved in the workplace incidents and sent to the Subcontractor and
the Ministry of Manpower to inform them of the individuals involved in the workplace
incidents.
Disclosure of the Banned Operators List
6

On or about 17 July 2019, unbeknownst to PBPL and without any authorisation from

PBPL, PBPL’s WSHO sent the Banned Operators List to a private Whatsapp group comprising
of workplace safety professionals in Singapore (the “Whatsapp Group”) along with the
following Whatsapp message:
“… [details of the incident]. Please look out for such operators in future at your
site.”

The Complaints were filed with the Commission between 19 and 20 July 2019 after the

Complainants came to know of the existence of the Banned Operators List and the fact that it
was being circulated amongst those in the construction industry.
8

GCPL’s WSHO was a member of the Whatsapp Group. When GCPL’s WSHO received

the Banned Operators List and message, he understood it to mean that the individuals listed in
the Banned Operators List (i.e. the Complainants) were banned from working at the Geylang
Worksite. As he oversaw the Clementi Worksite, he wanted to look out for the Complainants
should they come onto the Clementi Worksite.
9

On or about 24 July 2019, GCPL’s WSHO sent the Banned Operators List to GCPL’s

safety coordinator with instructions “to look out for these people and not to let them enter the
Clementi worksite”. Specifically, GCPL’s WSHO instructed GCPL’s safety coordinator to
print and paste a copy of the Banned Operators List in the guard room so that the security
guards could keep a lookout for the Complainants. However, GCPL’s safety coordinator
misunderstood these instructions. Instead of pasting a copy of the Banned Operators List in the
guard room of the Clementi Worksite, the word “BANNED” was added as a header to the
Banned Operators List and the list was pasted on the external façade of the Clementi Worksite
where it was visible to all persons walking onto the Clementi Worksite (the “Poster”).
10

According to GCPL’s WSHO, he had not noticed that the Poster was pasted on the

external façade of the Clementi Worksite as he usually drove into the worksite. While GCPL’s
WSHO claimed to have only noticed the Poster on the external façade in late September 2019
and intended to remove it, GCPL only took down the Poster after the Commission notified it
of the Complaints on or about 26 September 2019. The Poster had been displayed on the
external façade for about 2 months.
Findings and Basis for Determination
11

The issues to be determined in this case are:
(a)

whether PBPL is responsible for their WSHO’s disclosure of the Banned

Operators List;
(b)

if PBPL is responsible, whether PBPL contravened its obligations under the

Personal Data Protection Act 2012 (“PDPA”);
4

(c)

whether GCPL is responsible for their WSHO and safety coordinator’s

collection, use, and disclosure of the Banned Operators List; and
(d)

if GCPL is responsible, whether GCPL contravened its obligations under the

PDPA.
Whether PBPL is responsible for their WSHO’s disclosure of the Banned Operators List
12

Under section 53(1) of the PDPA, any act done, or conduct engaged in by an employee

in the course of his employment is treated as done or engaged in by his employer as well,
regardless of whether it was done or engaged in with the employer’s knowledge or approval.
Section 53(2) provides for a defence of reasonable diligence for offences under the PDPA,
where the employer had taken reasonable steps to prevent or reasonably reduce the risk of the
occurrence of the employee’s action or conduct that resulted in an unauthorised collection, use
and/or disclosure of personal data. For investigations into breaches of the PDPA that are not
offences — such as the present case — a similar standard of reasonable diligence may be
applied by virtue of section 11(1) of the PDPA, by considering whether the organisation had
acted reasonably in meeting its responsibilities under the PDPA.
13

In the present case, the Commission’s investigations found that PBPL’s WSHO was

not acting in the course of his employment when he disclosed the Banned Operators List to the
members of the Whatsapp Group:
(a)

first, even though PBPL’s WSHO compiled the Banned Operators List in the

course of his employment, there was no evidence that PBPL had directed him to share
the Banned Operators List in the Whatsapp Group. PBPL was not aware of the
Whatsapp Group’s existence and did not know that their WSHO was a member of the
Whatsapp Group; and
(b)

second, in sharing and disclosing the Complainants’ personal data in the Banned

Operators List to the members of the Whatsapp Group, PBPL’s WSHO had disregarded
his obligations of confidentiality under his employment contract:
“You shall keep confidential and not, during your employment, directly or
indirectly use, divulge, disclose or deliver to any person except as
authorized or required by your duties, or by law, and term in this letter of
5

any Confidential Information of the Company acquired by you in the
course of your employment.”
14

Thus, given that PBPL’s WSHO acted outside of the course of his employment when

he disclosed the Complainants’ personal data without their consent, section 53(1) of the PDPA
does not apply and the WSHO’s actions cannot be attributed to PBPL. Accordingly, PBPL did
not contravene its data protection obligations under the PDPA with regard to the disclosure of
the Complainants’ personal data in the Banned Operators List.
Whether GCPL is responsible for their WSHO and safety coordinator’s collection, use and
disclosure of the Banned Operators List
15

Similar to PBPL, it is doubtful if GCPL knew of the existence of the WhatsApp Group

or that it’s WSHO was a member thereof. GCPL’s WSHO probably also did not obtain the
Banned Operators List in the course of his employment, since his participation in the WhatsApp
Group was unsanctioned. However, the significant departure is that unlike PBPL’s WSHO,
GCPL’s WSHO was acting in the course of his employment when he instructed GCPL’s safety
coordinator to put up a copy of the Banned Operators List in the Clementi Worksite
guardhouse. The use of the Complainants’ personal data was expressly professed to be for the
purpose of screening and restricting the entry of the Complainants onto the Clementi Worksite.
Similarly, GCPL’s safety coordinator was also acting in the course of his employment when
he pasted the Poster on the external façade of the Clementi Worksite, thereby disclosing the
Complainants’ personal data.
16

Accordingly, pursuant to section 53(1) of the PDPA, GCPL’s WSHO and safety

coordinator’s collection, use, and disclosure of the Complainants’ personal data were the
actions of GCPL for which it was responsible.
Whether GCPL has contravened its obligations under the PDPA
17

Under section 13 of the PDPA, organisations are prohibited from collecting, using or

disclosing an individual’s personal data unless the individual gives, or is deemed to have given,
his consent for the collection, use or disclosure of his personal data, or the collection, use or
disclosure without consent is authorised under the PDPA or any other written law (the
“Consent Obligation”).
6

On the present facts, the disclosure of the Complainants’ personal data without their

consent was not authorised under the PDPA or any other written law; nor could disclosure be
supported by any extant exceptions for the Consent Obligation. It was clear from the facts that
the Complainants had not voluntarily provide their personal data to GCPL. GCPL therefore
needed to have obtained the Complainants’ consent before disclosing their personal data by
pasting the Banned Operators List onto the façade of the Clementi Worksite. However, GCPL
failed to do so.
19

While it is arguable that the use of the Banned Operators List within the guardroom and

confined to the security personnel may have been acceptable, especially if the context of the
information had been provided and clear instructions had been given that the Banned Operators
List be restricted to private reference by security personnel on duty. However, the present case
went beyond what a reasonable person would consider appropriate in the circumstances. The
information came from an informal source – i.e. the WhatsApp Group – and GCPL made a
decision to ban the Complainants from the Clementi Worksite on the basis of the Banned
Operators List. These are decisions that GCPL may make as a private commercial enterprise.
The Banned Operators List could have been handled more discretely and used more
responsibly. However, pasting it on the external façade of the Clementi Worksite such that it
could be seen any passer-by fell below the standard of reasonableness that is expected from
GCPL.
20

In the circumstances, GCPL breached the Consent Obligation.

The Deputy Commissioner’s Directions
21

In determining the directions, if any, to be imposed on GCPL under section 48I of the

PDPA, I took into account the following mitigating factors:
(a)

the incident occurred because GCPL’s safety coordinator (who was a new

employee at the time) misunderstood the instructions given to him;
(b)

the incident had originated from GCPL’s WSHO whose actions arose out of

concern for the safety of the Clementi Worksite, in view of the alleged conduct of the
Complainants, and in the interest of his employer;

(c)

there was limited disclosure of personal data of the Complainants and any

disclosure would have been limited to those who entered the Clementi Worksite on
foot; and
(d)

upon being notified of the Complaints, GCPL took prompt remedial action by

removing the Banned Operators List poster from the Clementi Worksite.
22

Having considered all the relevant factors of this case, I hereby issue a Warning to

GCPL. No further directions are necessary given the remedial actions that have already been
taken by GCPL.

YEONG ZEE KIN
DEPUTY COMMISSIONER FOR PERSONAL DATA PROTECTION

",Warning,3df9d84ac2b94b9eceb608d856f98239db7a49bc
63,63,1,952,A review application under section 28 (now known as section 48H(1)(a)) of the PDPA was conducted following a failed request by an individual to obtain his full unredacted internal evaluation report prepared by HSBC Bank (Singapore) Limited for the purpose of evaluating his credit card application.,"[""Finance and Insurance"", ""Access and Correction"", ""Evaluation"", ""Opinion Data""]",2021-05-12,https://www.pdpc.gov.sg/-/media/Files/PDPC/PDF-Files/Commissions-Decisions/Decision--HSBC-Bank-Singapore-Limited--10032021.pdf,,Outcome of a Review Application Involving an Individual and HSBC Bank,https://www.pdpc.gov.sg/all-commissions-decisions/2021/05/outcome-of-a-review-application-involving-an-individual-and-hsbc-bank,2021-05-12,"PERSONAL DATA PROTECTION COMMISSION

[2021] SGPDPC 3
Case No. DP-1810-B2892R

In the matter of a review under section 48H(1)(a)
of the Personal Data Protection Act 2012 and
of the Personal Data Protection (Enforcement) Regulations 2021

Between

[Redacted]
… Applicant
And

HSBC Bank (Singapore) Limited
… Respondent

DECISION

HSBC Bank (Singapore) Limited
Yeong Zee Kin, Deputy Commissioner — Case No. DP-1810-B2892R
10 March 2021

Background
1

The Respondent, HSBC Bank (Singapore) Limited (“HSBC”), is a full-service bank in

Singapore. HSBC’s personal banking offerings include credit card facilities to individuals,
offered subject to a process of application and approval by the bank. Sometime in 2018, the
Applicant applied to HSBC for a credit card, but was unsuccessful. Dissatisfied, he requested
HSBC to provide him with a copy of the bank’s internal evaluation report prepared for the
purpose of evaluating his credit card application (“the Report”).
2

In response to the Applicant’s request, HSBC furnished a copy of the Report but with

some fields redacted (“the Redacted Data”). HSBC’s position was that they were not obliged
to disclose the Redacted Data to the Applicant, as the Redacted Data constituted opinion data
kept solely for an evaluative purpose, an exception to the Access Obligation under paragraph
1(a) of the Fifth Schedule (“the Evaluative Purpose Exception”).
3

The Applicant maintained that he was entitled to the full unredacted Report, and

approached the Personal Data Protection Commission (the “Commission”) for assistance. The
Commission attempted to facilitate an amicable resolution between the parties. When attempts
to facilitate an amicable resolution were unsuccessful, the Commission informed the Applicant
of his option to make a review application under the then section 28 of the PDPA (now, section
48H(1)(a) of the PDPA) (“the Review Application”).
4

The Applicant elected to take this option on 18 March 2020. As HSBC’s position on

the Review Application was extensively set out in its prior correspondence with the
Commission, these were (with HSBC’s consent) treated as the Respondent’s response for the
purposes of Regulation 6 of the Personal Data Protection (Enforcement) Regulations 2014
(“the Response”). In the Response, in addition to the Evaluative Purpose Exception, HSBC

cited additional grounds to justify not disclosing the Redacted Data to the Applicant. Despite
the Commission’s invitation, the Applicant did not submit any reply to the Response.
Findings and basis for determination
5

The issues that arise for my determination in this Review Application are:
(a)

Whether the Report is personal data of the Applicant; and

(b)

If so, whether the Evaluative Purpose Exception (or any other exception under

the PDPA or other written law) applies so as to justify HSBC’s refusal to give the
Applicant access to the Redacted Data.
The Access Obligation
6

The Applicant’s request for access to the Report should be viewed as a data subject

access request made pursuant to section 21(1) of the Personal Data Protection Act 2012
(“PDPA”). Section 21(1) of the PDPA gives a data subject the right to access personal data
about him that is in an organisation’s possession or under its control (“the Access
Obligation”). The data subject’s right of access is moderated by section 21(2) of the PDPA
which allows an organisation to invoke any of the exceptions listed in the Fifth Schedule of the
PDPA to decline the data subject access request.
7

The Access Obligation should not be examined in isolation. The Access Obligation

enables a number of neighbouring obligations: the Purpose Limitation Obligation (section 18
of the PDPA), the Correction Obligation (section 22 of the PDPA) and the Accuracy
Obligation (section 23 of the PDPA). The Access Obligation enables the data subject to
ascertain what personal data about him an Organisation possesses or controls, and also how it
has been used or disclosed. It empowers the data subject to ask for an account of how personal
data about him has been collected, used or disclosed: section 21(1)(b) of the PDPA. It also
enables the data subject to ascertain that personal data about him is correct, and to request for
correction of errors or omissions: section 22(1) of the PDPA. This in turn supports the
organisation’s use of personal data. The Accuracy Obligation requires an organisation to ensure
that personal data that it uses when making decisions that affect an individual is accurate and
complete: section 23(a).

The PDPA respects a fundamental distinction between ensuring that good quality data

is available to organisations that make use of them to make decisions, and the decision and
decision-making process. Whereas the Access and Correction Obligations support the former
by empowering the individual in the manner described in the preceding paragraph, the Fifth
and Sixth Schedules contain a number of exceptions that are intended to preserve the
confidentiality of the decision-making process e.g. evaluative purpose and trust administration.
9

I thought it helpful to preface the relationships of these obligations before providing the

reasons for my decision on this Review Application.
Is the Report personal data of the Applicant?
10

Section 2(1) of the PDPA defines “personal data” as data, whether true or not, about an

individual who can be identified (a) from that data; or (b) from that data and other information
to which the organisation has or is likely to have access. In the Commission’s Advisory
Guidelines on Key Concepts in the PDPA, the following guidance has been provided on when
data would be considered “personal data” for the purposes of the PDPA, at [5.2] and [5.4]:
(a)

The term “personal data” is not intended to be narrowly construed and may

cover different types of data about an individual and from which an individual can be
identified, regardless of whether such data is true or accurate, or whether the data exists
in electronic or other form.
(b)

There are two principal considerations. First, is the nature or purpose of the

information to be data about an individual or which relates to the individual. Second,
the individual should be identifiable from the data on its own, or from that data and
other information to which the organisation has or is likely to have access.
11

The Report was prepared for the purposes of evaluating the Applicant’s application for

credit card facilities. It contained information about him that was relevant to deciding whether
credit card facilities should be extended by HSBC. The Report contained various data fields,
some of which were populated with text, and some left blank. Some of the populated fields in
the Report were redacted by HSBC when a copy was provided to the Applicant (i.e. the
Redacted Data). Since the Report contains information about the Applicant, who is identifiable
from the information, and the Report was prepared for the purpose of making a decision

concerning his application for credit card facilities, the Report is therefore the personal data of
the Applicant.
12

In its Response, HSBC described the Redacted Data as opinion data auto-generated by

HSBC’s proprietary algorithm that determined an individual’s suitability for a credit card by
analysing data from various sources. The data analysed included (i) information provided by
the Applicant in his credit card application form such as his age, education level, income and
employment information, and (ii) data obtained from third parties such as other banks or the
Credit Bureau Singapore. HSBC also explained that the Redacted Data did not comprise of
actual data from these sources, but was data derived from information obtained from these
sources.
13

I did not consider the fact that the Redacted Data was algorithmically generated data to

be relevant in determining whether they formed part of the Applicant’s personal data. The
primary focus is whether the information is about an identified or identifiable individual. It
matters not whether the data was collected directly from the data subject, from a third-party
source or derived from data from either (or both) of such sources. So long as the information
is about the individual and it is in the possession or under the custody of the organisation, it is
personal data.
14

For the purpose of deciding the applicability of the Evaluative Purpose Exception

subsequently, I need to be satisfied that the Redacted Data is opinion data. HSBC’s argument
is that the Redacted Data was derived after an analysis of primary data based on business rules
that are expressed in its proprietary algorithm. For the purpose of this Review Application,
HSBC provided the Report in the clear. There are five fields that were redacted: four were
algorithmically generated and one contained type-written information. I am satisfied that the
Redacted Data is not merely a reproduction of personal data obtained from a third-party source
nor are they the result of simple arithmetic operations; they are expressions of opinions after
data processing. I therefore accept the argument that the application of business rules in the
algorithmic analysis yielded opinions, and by virtue of this, the Redacted Data is opinion data.
Therefore, the Redacted Data is opinion data that forms part of the Applicant’s personal data
that HSBC has in its possession and control; and the Redacted Data is potentially subject to the
Access Obligation, unless HSBC is able to rely on an applicable exception.

Can HSBC rely on the Evaluative Purpose Exception (or other grounds) to decline access to
the Redacted Data?
15

The Fifth Schedule allows an organisation to decline providing access to “opinion data

kept solely for an evaluative purpose”: para 1(a) of the Fifth Schedule. Section 2(1) of the
PDPA defines “evaluative purpose” to mean:
“(a) for the purpose of determining the suitability, eligibility or qualifications of the
individual to whom the data relates —
(i) for employment or for appointment to office;
(ii)

for promotion in employment or office or for continuance in employment
or office;

(iii)

for removal from employment or office;

(iv)

for admission to an education institution;

(v)

for the awarding of contracts, awards, bursaries, scholarships, honours or
other similar benefits;

(vi)

for selection for an athletic or artistic purpose; or

(vii)

for grant of financial or social assistance, or the delivery of appropriate
health services, under any scheme administered by a public agency;

(b) for the purpose of determining whether any contract, award, bursary, scholarship,
honour or other similar benefit should be continued, modified or cancelled;
(c) for the purpose of deciding whether to insure any individual or property or to
continue or renew the insurance of any individual or property; or
(d) for such other similar purposes as may be prescribed by the Minister”
[emphasis added]
16

It is clear from the words emphasised in bold in the definition above that the Evaluative

Purpose Exception is intended to cover the decision-making process: in other words, the
evaluation before a decision is made. The definition enumerates a number of decisions that
organisations have to make from time to time: see the words emphasised in italics. Thus, the
Evaluative Purpose Exception operates to keep opinions that form part of the decision-making
process confidential. Data subjects do not have the right to access personal data that is
contained in such opinions: section 21(2) read with para 1(a) of the Fifth Schedule; nor do they
have the right to request corrections: section 22(6) and 22(7) read with para 1(a) of the Sixth
Schedule.

In the present Review Application, the Applicant had applied for credit card facilities.

Limb (a) of the definition is the relevant one. HSBC is evaluating his suitability or eligibility
for the credit card facilities. The evaluation will result in a decision whether to extend to him
the credit card facilities that he had applied for, which will entail the award of a contract: i.e.
sub-section (v) “for the awarding of contracts, awards, bursaries, scholarships, honours or
other similar benefits”. The operative decision here is to make an award; the subject matter of
the decision covers a range of things. Some are in the nature of a bilateral relationship, eg
contracts, bursaries and scholarships; some a unilateral conferment of a status, eg honours or
similar benefits. Thus, HSBC was using the opinion data to evaluate whether to award the
contract to the Applicant. I therefore find that HSBC was entitled to rely on the Evaluative
Purpose Exception to decline giving the Applicant access to the Redacted Data.
18

Section 21(5) of the PDPA contemplates occasions, such as the present, where

documents may contain personal data that the data subject is entitled to access commingled
with other personal data that the organisation may decline to provide access to. Thus, HSBC is
entitled to rely on the Evaluative Purpose Exception to exclude the Redacted Data from the
copy of the Report that was furnished to the Applicant.
19

Even though HSBC declined to disclose the Redacted Data, it had provided to the

Applicant two publications: (a) HSBC’s Principle for the Ethical Use of Big Data and AI and
(b) HSBC’s Credit Decisioning Policy Statement. These publications provide information
about how AI and Big Data are used in an ethical manner by HSBC and how technology is
used to conduct credit facility assessments. I found the Credit Decisioning Policy Statement
relevant. It provides a description of the type of opinions that the majority of the Redacted Data
conveyed. Even though HSBC was entitled to decline providing access to the Redacted Data,
it had acted reasonably by providing information about how it uses data and technology to
conduct credit facility assessments. From the perspective of accountability and disclosure of
policies and practices, HSBC had acquitted itself.
20

For completeness, HSBC also cited various other reasons in its Response to justify its

refusal to give the Applicant access to the Redacted Data. In view of my conclusion that HSBC
was entitled to rely on the Evaluative Purpose Exception to decline providing access to the
Redacted Data, it is unnecessary for me to consider these additional grounds put forth by HSBC

in full. Nevertheless, I set out these additional grounds and the reasons why I did not think that
they merited full consideration:
(a)

Citing paragraph 1(g) of the Fifth Schedule of the PDPA, HSBC argued that

disclosure of the Redacted Data would reveal confidential commercial information that
would affect HSBC’s competitive position. From my perusal of the Report, I did not
think that the Redacted Data would disclose or allow for the reverse-engineering of
“confidential commercial information” pertaining to HSBC’s credit card application
evaluation process that would affect its competitive position. On the contrary, their
Credit Decisioning Policy Statement provided an ample description of the majority of
the Redacted Data.
(b)

Citing paragraph 1(h) of the Fifth Schedule of the PDPA, HSBC argued that the

Redacted Data was personal data collected for the purposes of an investigation and that
this investigation and associated proceedings and appeals had not yet been completed.
Based on the information provided, there was no ongoing ‘investigation” within the
meaning of section 2(1) of the PDPA. Client due diligence or customer information
checks for the purposes of a credit card application were not “investigations” in this
sense.
(c)

Citing paragraph 1(j)(ii) of the Fifth Schedule of the PDPA, HSBC argued that

the burden or expense of providing access to the Redacted Data would be unreasonable
considering the volume of credit application applications that HSBC received daily.
This was an assertion unsupported by evidence. It was not unreasonably burdensome
or expensive for HSBC to respond to the Applicant’s access request, and the fact that
the Applicant’s request might lead to other individuals making similar requests was not
a relevant consideration.
(d)

Citing paragraph 1(j)(v) of the Fifth Schedule to the PDPA, HSBC argued that

the Applicant’s request was frivolous and vexatious as the Applicant had full
knowledge of the personal data and financial information that he had himself provided
by way of his credit card application only some 2 weeks prior to his access request. I
did not consider the Applicant’s request to be frivolous or vexatious as he had not
requested for the same data which he had provided to HSBC in his credit card

application form, but had requested for the bank’s opinion data in the Report, which he
had no knowledge of but was interested in.
(e)

Finally, HSBC argued that MAS Notice 626 issued on 24 April 2015 (pursuant

to section 27B of the Monetary Authority of Singapore Act) took precedence over
HSBC’s obligations under the PDPA by virtue of section 4(6) of the PDPA, and allowed
HSBC to refuse access to the Redacted Data. MAS Notice 626 deals with anti-money
laundering and terrorism financing. Having considered the Redacted Data in the clear,
I did not think that this MAS Notice was relevant.
The Deputy Commissioner’s Decision
21

Pursuant to section 48H(2)(a) of the PDPA, and for the reasons set out above, I confirm

HSBC’s refusal to provide the Applicant with access to the Redacted Data.

YEONG ZEE KIN
DEPUTY COMMISSIONER
FOR PERSONAL DATA PROTECTION

",,c714658b21945c62deecbceeab6abcc2739aa9f8
64,64,1,952,"A warning was issued to Flying Cape, a data intermediary, for failing to put in place reasonable security arrangements to protect the personal data of 191 users of a website. Flying Cape was managing the website on behalf of its client.","[""Protection"", ""Warning"", ""Information and Communications"", ""Ransomware"", ""Data Intermediary"", ""Online Storage Bucket""]",2021-04-15,https://www.pdpc.gov.sg/-/media/Files/PDPC/PDF-Files/Commissions-Decisions/Decision---Flying-Cape-Pte-Ltd---17032021.pdf,Protection,Breach of the Protection Obligation by Flying Cape,https://www.pdpc.gov.sg/all-commissions-decisions/2021/04/breach-of-the-protection-obligation-by-flying-cape,2021-04-15,"PERSONAL DATA PROTECTION COMMISSION
Case No. DP-2011-B7385
In the matter of an investigation under section 50(1) of the
Personal Data Protection Act 2012
And
(1) Flying Cape Pte Ltd
(2) ACCA Singapore Pte Ltd

SUMMARY OF THE DECISION

Sometime between 25 September 2020 to 5 October 2020, the personal data of 191 users
(the “Affected Individuals”) of www.accapdhub.com (the “Website”) was exfiltrated
by an unauthorised party (the “Incident”).The exfiltrated personal data comprised of the
names, email addresses and contact numbers of the Affected Individuals (“the
Exfiltrated Data”).

The Website was owned by ACCA Singapore Pte Ltd (“ACCA”), but hosted, managed,
and operated by Flying Cape Pte Ltd (“FCPL”) as ACCA’s data intermediary. FCPL
notified the Personal Data Protection Commission (the “Commission”) of the Incident
on 12 November 2020, after having received a ransom demand in respect of the
Exfiltrated Data.

Sometime in early September 2020, as part of its management of the Website, FCPL
extracted the personal data of the Affected Individuals from the database of the Website

into an excel file. An FCPL employee who was assigned to work with the excel file failed
to protect the file with a password or encrypt it as required by FCPL’s IT policy.
Moreover, the employee incorrectly stored the excel file in a publicly accessible online
storage bucket, as opposed to the correct, secured storage bucket. These lapses were
believed to have led to the Incident.

Pursuant to section 53(1) of the PDPA, FCPL is liable for acts done by employees. The
question therefore becomes whether FCPL had taken reasonable steps to prevent or
detect mistakes such as the one made by the employee. The investigations did not surface
any arrangements to supervise or verify its employees’ compliance with its internal
policies or detect non-compliance. The Deputy Commissioner for Personal Data
Protection therefore found that FCPL had breached the Protection Obligation under
section 24 of the Personal Data Protection Act 2012 (the “PDPA”) in respect of the
Exfiltrated Data.

As the data controller and owner of the Website, ACCA owed the Protection Obligation
in respect of the Exfiltrated Data as well. The Deputy Commissioner is satisfied that
ACCA discharged this obligation by (i) carrying out a due diligence assessment of
FCPL’s data protection policies and practices before their engagement, and (ii) by
stipulating data protection requirements in its contract when engaging with FCPL.

Taking into account the circumstances of the case, and in particular the factors below,
the Deputy Commissioner for Personal Data Protection found ACCA not in breach of
the PDPA and decided to issue a Warning to FCPL:

a. The number of the Affected Individuals was low;
b. The Exfiltrated Data was of a low sensitivity;
c. FCPL took immediate remedial actions to prevent the occurrence of a similar
incident; and
d. FCPL voluntary notified the Commission of the Incident.

In view of the remedial actions taken by FCPL, no directions were issued.

",Warning,816c141c71713a45a7d40c205c4815198b33af42
65,65,1,952,A warning was issued to St. Joseph's Institution International for failing to put in place reasonable security arrangements to protect the personal data in its possession. The incident resulted in the personal data being at risk of unauthorised access.,"[""Protection"", ""Warning"", ""Education"", ""Google Chrome Extension"", ""Virus""]",2021-04-15,https://www.pdpc.gov.sg/-/media/Files/PDPC/PDF-Files/Commissions-Decisions/Decision--St-Josephs-Institution-International-Ltd--12032021.pdf,Protection,Breach of the Protection Obligation by St. Joseph's Institution International,https://www.pdpc.gov.sg/all-commissions-decisions/2021/04/breach-of-the-protection-obligation-by-st-josephs-institution-international,2021-04-15,"PERSONAL DATA PROTECTION COMMISSION
Case No. DP-2010-B7196
In the matter of an investigation under section 50(1) of the
Personal Data Protection Act 2012
And
St. Joseph’s Institution International Ltd.

SUMMARY OF THE DECISION
1. On 16 October 2020, St Joseph’s Institution International Ltd. (the
“Organisation”) informed the Personal Data Protection Commission that a file
listing the personal data of 3155 parents and students (“the File”) was found
on a website called VirusTotal (the “Incident”).
2. The Incident occurred on or around 13 October 2020 when a staff of the
Organisation downloaded and deployed a Google Chrome browser extension
developed by VirusTotal for additional security scanning. Unknown to the staff,
apart from security scanning, the extension also forwarded scanned samples
to premium members of VirusTotal (the “3rd Parties”) for security analysis and
research. This use of samples was made known in VirusTotal’s privacy policy
covering the use of the extension.
3. As a result of the Incident, the personal data of 3155 individuals including both
parents and students were put at risk of unauthorised access. The personal
data affected included the names of parents and students, parents’ email
addresses, students’ date of birth, students’ classes, students’ year and grades.
4. Users of the VirusTotal Chrome extension would have to agree to VirusTotal’s
Privacy Policy, which provides that once files are uploaded to the VirusTotal
website for scanning, copies of these files will be kept by VirusTotal and shared
with their subscribers for research purposes. The risk of such file sharing and
in turn disclosure of personal data to 3rd Parties ought to have been known to
the said staff of the Organisation, but was overlooked due to oversight. Such
oversight could have been prevented if the Organisation had sufficiently robust
processes for assessing such risks prior to deploying downloaded software,
including Chrome Extensions. However, the Organisation lacked such
processes.

5. Nevertheless, the Organisation took prompt action to mitigate the effects of the
breach by contacting VirusTotal immediately to remove the File and notified all
affected individuals. While personal data was disclosed, it was limited to
premium members of VirusTotal for research purposes only.
6. On the facts, the Deputy Commissioner for Personal Data Protection found the
Organisation in breach of the Protection Obligation under section 24 of the
Personal Data Protection Act 2012. However, in consideration of the limited risk
of personal data being disclosed, and the Organisation’s commitment to
improve its processes, a Warning was issued to the Organisation.
7. The Commission reminds all organisations that they must have sufficiently
robust processes to obtain a functional understanding of software to be
deployed, in order to assess the security risks to personal data in their
possession or control. Failure to do so would be breach of the Protection
Obligation.

",Warning,8c090a898191be97b97f6c86d047026a0a44edff
66,66,1,952,"Chapel of Christ the Redeemer failed to put in place reasonable measures to protect its members' personal data. Further, it did not have written policies and practices necessary to comply with the PDPA.","[""Accountability"", ""Protection"", ""Directions"", ""Others"", ""No Policy"", ""Access control"", ""Indexing""]",2021-04-15,https://www.pdpc.gov.sg/-/media/Files/PDPC/PDF-Files/Commissions-Decisions/Decision---Chapel-of-Christ-the-Redeemer---290121.pdf,"Accountability, Protection",Breach of the Protection and Accountability Obligations by Chapel of Christ the Redeemer,https://www.pdpc.gov.sg/all-commissions-decisions/2021/04/breach-of-the-protection-and-accountability-obligations-by-chapel-of-christ-the-redeemer,2021-04-15,"PERSONAL DATA PROTECTION COMMISSION
Case No. DP-2010-B7132

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

SUMMARY OF THE DECISION

On 6 October 2020, Chapel of Christ the Redeemer (the “Organisation”) informed the
Personal Data Protection Commission (the “Commission”) that a file (the “File”)
containing personal data of 815 members’ name, NRIC, address, date of birth, marital
status, email address, mobile and residential phone number was inadvertently disclosed
online.

Investigations revealed that a staff had accidentally uploaded the File (which was
supposed to be an internal document) onto the sub-directory on 24 November 2019. The
Organisation only discovered the matter on 8 September 2020 when a member of the
Organisation performed a Google search of another member’s name and found a Google
search result of the File.

The Organisation admitted that there were no access controls to the sub-directory prior
to the incident as the sub-directory was intended to be accessible to public. As a result,
the File was indexed by search engines and showed up in online search results. The
Organisation also admitted that at the time of the incident, the Organisation had not
developed any internal policies and practices to ensure compliance with the Personal
Data Protection Act 2012 (the “PDPA”). In particular, there was no system of checks for
the uploading of files on the Organisation’s website.

Fortuitously, it appeared that the access to the File was minimal – based on Google
Analytics Report, save for the Organisation’s member who discovered the File on the
internet on 8 September 2020, there was only one other access to the File on 9 December
2019, and the access only lasted for approximately 1 minute.

Following the incident, the Organisation disabled the search engine indexing to the subdirectory, password-protected all files with members’ data, and implemented a weekly
check of all files uploaded onto the website to detect any accidental uploading of
incorrect files; and a policy to delete files that are on the website for more than three
months. The Organisation has also informed the Commission that it intends to engage a
consultant to conduct PDPA training for its staff, as well as to review the data protection
processes within the Organisation to ensure compliance with the PDPA.

In view of the facts stated at [3] above, the Deputy Commissioner for Personal Data
Protection found the Organisation in breach of section 12 of the PDPA (the obligation to

develop and implement data protection policies and practices), and section 24 of the
PDPA (the obligation to protect personal data in an organisation’s possession or under
its control by making reasonable security arrangements).

In determining the directions to be imposed on the Organisation under section 29 of the
PDPA, the following factors were taken into account:

(a) The Organisations had voluntarily notified the Commission of the incident, fully
cooperated with the Commission’s investigations and implemented prompt remedial
measures to address the breach; and

(b) There was minimal access to the File and no evidence that the personal data had been
misused.

In the circumstances, the Deputy Commissioner would not be imposing any financial
penalty on the Organisation. However, in light of the Organisation’s lack of the necessary
data protection policies and practices, the Deputy Commissioner hereby directs the
Organisation to:

(a) Develop and implement internal data protection policies and practices to comply
with the provisions of the Act within 90 days from the date of the direction, and

(b) Inform the Commission within 1 week of implementation of the above.

",Directions,3af9997c53409121b23cd38f9ec106f784e3648c
67,67,1,952,"A financial penalty of $29,000 was imposed on Tripartite Alliance for failing to put in place reasonable security arrangements to prevent the unauthorised access of approximately 20,000 individuals’ and companies’ data stored in its customer relationship system database.","[""Protection"", ""Financial Penalty"", ""Social Service"", ""Ransomware"", ""Scope of Duties"", ""Third Party Vendor""]",2021-04-15,https://www.pdpc.gov.sg/-/media/Files/PDPC/PDF-Files/Commissions-Decisions/Decision---Tripartite-Alliance-Limited---16032021.pdf,Protection,Breach of the Protection Obligation by Tripartite Alliance,https://www.pdpc.gov.sg/all-commissions-decisions/2021/04/breach-of-the-protection-obligation-by-tripartite-alliance,2021-04-15,"PERSONAL DATA PROTECTION COMMISSION
Case No. DP-2003-B6000
In the matter of an investigation under section 50(1) of the
Personal Data Protection Act 2012
And
Tripartite Alliance Limited

SUMMARY OF THE DECISION
1.

On 3 March 2020, Tripartite Alliance Limited (the “Organisation”) notified the Personal
Data Protection Commission (the “Commission”) that a server hosting its customer
relationship management (“CRM”) system was infected with ransomware on or around
17 February 2020.

The Organisation subsequently requested for this matter to be handled under the
Commission’s expedited breach decision procedure. In this regard, the Organisation
voluntarily provided and unequivocally admitted to the facts set out in this decision. It
also admitted that it was in breach of section 24 of the Personal Data Protection Act (the
“PDPA”).

The Incident
3.

The Organisation is in the business of promoting fair and progressive employment
practices, as well as providing mediation and advice in employment–related disputes.
1

The CRM system is a Software-as-a-Service (“SaaS”) solution provided by a software
service provider engaged by the Organisation (the “Vendor”). The Organisation uses the
CRM system to handle employment-related enquiries, feedback and complaints.

At the time of the incident, the CRM system contained approximately 12,000 individuals’
and 8,000 companies’ data (including information of the companies’ representatives).
The types of data affected for each individual varied, but may include an individual’s
name, identification number, contact number, email address, age, race, marital status,
salary and compensation amount (if applicable).

On 17 February 2020, the CRM system was unavailable to users. The Vendor managed
to restore the CRM system from a back-up copy within the next three hours.

Upon investigations, the Organisation determined that the CRM system suffered a
ransomware attack. In particular, security logs obtained from the Vendor showed that
hacking attempts were made on the database server between 7 and 14 February 2020.

The Organisation claimed that it had, since June 2019, expanded the scope of the IT
services procured from the Vendor to include security monitoring services for the CRM
system, such as the blocking of cyber-attacks based on alerts. However, there was
inadequate process put in place to ensure that the Vendor proactively monitor the alerts
and take actions to block malicious activities in a timely manner. Nevertheless, the
2

Organisation accepts that it had the responsibility to ensure that the Vendor had the same
understanding on its duty of care under the monitoring services contract and to oversee
and supervise the work of the Vendor through clear instructions on regular reporting and
updates by the Vendor.

Following the incident, the Organisation started close monitoring of the Vendor’s IT
services support on a weekly basis to ensure timely update of patches and follow-ups on
security alerts received. The Organisation also undertook an organisation-wide review to
strengthen its management of all its third-party IT service providers, such as requesting
these service providers to conduct cybersecurity audits, vulnerability assessment and
penetration testing for the Organisation’s existing IT systems. The Organisation also
informed the Commission that it will be migrating to a new CRM system and is currently
working to terminate the existing CRM system.

10.

The Organisation informed the Commission that the database in the CRM system was
not protected by encryption at the time of the incident, which made the database
vulnerable for exposure. However, there was no evidence that the hacker had exfiltrated
the database.

The Organisation’s Admission and the Commission’s Decision
11.

The Organisation admitted that it had breached the Protection Obligation under section
24 of the PDPA in failing to ensure that the Vendor had duly discharged its contractual
data protection obligations. In particular, the Organisation admitted that it had not
3

monitored the Vendor’s performance to ensure that the Vendor met the required
information security standards.

12.

As stated in previous decisions by the Commission1, organisations have to give proper
instructions and exercise reasonable oversight over their vendors to ensure that their
outsourced providers are indeed delivering the services contracted. Without reasonable
oversight, the risk from any failure will fall on the organisation. In the circumstances, the
Commissioner found that the Organisation was in breach of the Protection Obligation
under section 24 of the PDPA.

13.

As for the Vendor, it was a SaaS provider who provided the CRM system, including
maintenance support, and security monitoring services. These services did not entail the
processing of personal data. As such, the Vendor was not a “data intermediary” of the
Organisation. Accordingly, the Vendor was not responsible for the protection of the
individuals’ personal data under the PDPA in respect of the incident.

14.

In determining the directions to be imposed on the Organisation for the breach, the
Commissioner took into account the following factors:

See for example, Re Smiling Orchid (S) Pte Ltd and Ors [2016] SGPDPC 19, Re Royal Caribbean Cruises
(Asia) Pte Ltd [2020] SGPDPC 5, and Re SCAL Academy Pte. Ltd. [2020] SGPDPC 2.

Aggravating
(a) The high number of affected individuals, which is approximately 20,000;
(b) The nature of the affected data. In particular, the database contained details of
employment-related complaints and disputes. Individuals would expect a high level
of confidence when they convey such matters to the Organisation for handling;

Mitigating
(c) The Organisation’s upfront admission of breach of the Protection Obligation, and the
prompt remedial actions to mitigate the effects and prevent recurrence of the incident;
and
(d) There was no evidence of exfiltration of the database in the CRM system.

15.

On account of the above, the Organisation is directed to pay a financial penalty of
$29,000 within 30 days from the date of this direction. In view of the remedial action of
the Organisation, the Commission will not be issuing any other directions.

",Financial Penalty,0cdce22d84405d3787ba0a1ff0507d00cb8cec7f
68,68,1,952,"Jigyasa was found in breach of the PDPA. First, Jigyasa failed to put in place reasonable measures to protect employee assessment reports on its website. Second, it did not appoint a data protection officer. Lastly, it did not have written policies and practices necessary to ensure its compliance with the PDPA. An application for reconsideration was filed against the decision in Re Jigyasa [2020] SGPDPC 9. Upon review and careful consideration of the application, directions in the decision were varied in the Reconsideration Decision and a financial penalty of $30,000 was imposed on Jigyasa.","[""Accountability"", ""Protection"", ""Financial Penalty"", ""Professional"", ""Scientific and Technical"", ""No Policy"", ""No DPO"", ""Public access"", ""No pre-launch testing""]",2021-03-11,https://www.pdpc.gov.sg/-/media/Files/PDPC/PDF-Files/Commissions-Decisions/Decision---Jigyasa---30032020.pdf,"Accountability, Protection",Breach of the Protection and Accountability Obligations by Jigyasa,https://www.pdpc.gov.sg/all-commissions-decisions/2021/03/breach-of-the-protection-and-accountability-obligations-by-jigyasa,2021-03-11,"PERSONAL DATA PROTECTION COMMISSION

[2020] SGPDPC 9
Case No DP-1707-B0922

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

And

Jigyasa
(UEN: 52948595L)

… Organisation

DECISION

Jigyasa
[2020] SGPDPC 9
Tan Kiat How, Commissioner — Case No DP-1707-B0922
30 March 2020

Introduction
1

This case concerns the unauthorised disclosure of employee assessment reports, such
as 360 Feedback Reports and evaluation reports (collectively, the “Reports”), on the
website (“Website”) of Jigyasa (the “Organisation”), a human resource and
management consultancy business.

Material Facts
2

The Organisation is a business operated by a sole proprietor with one part-time
employee. The Reports were generated based on survey results collected by the
Organisation via its web application (the “Web Application”) and stored in a folder on
the server which hosted the Web Application. Reports documented 360 degree feedback
on employees of the Organisation’s clients, based on evaluation by their subordinates,
supervisors and/or peers. The feedback included character qualities, for example
whether they were considered fair, honest, reliable and trusted, demonstrated
professional behaviour at all times or had good technical knowledge. Each of these
character qualities was given an average rating from a scale of 1 to 10, with 9-10 being
an exceptional strength and 1-2 being below expectations. These Reports
comprehensively set out such information for each named individual employee of the
Organisation’s clients. There is also a section which provides verbatim comments from
respondents (e.g. “handle more complex responsibilities”, “slower support”). Some of
the Reports also included individual employees’ qualities, such as leadership, integrity,
decision-making, initiative, and professional disposition, ranked against their
colleagues.

On 10 July 2017, the Personal Data Protection Commission (the “Commission”)
received complaints from 3 individuals (the “Complainants”) alleging that when they
searched their names on the Internet, the search results included links to copies of their
360 Feedback Reports, and these reports were accessible through the links (the
“Incident”).

When notifying the Commission, the Complainants stated that they expected these
Reports to be private and confidential and that the disclosure of their 360 Degree
Feedback Report would have a significant impact on their job prospects and career
options. One of the Complainants alleged that as the industry the Complainant worked
in is “extremely niche”, “this could be the reason [he has] not been successful in his
job interviews over the past 2 years”. No evidence was adduced to support such claims.
Nevertheless, the possibility that the information contained in the Reports may have
been accessed by a prospective employer’s human resource personnel as they
conducted due diligence on job applications cannot be discounted.

The Organisation did not appear to be familiar with the security arrangements of its
Website and was not able to provide clear accounts on what led to the Incident during
the course of the investigation. In this regard, it was noted that the Organisation had
ceased the use of the Web Application in 2010, some 7 years before the Commission’s
investigation. The Organisation initially claimed that it did not know that when a client
requested for a 360 Feedback Report using the Web Application, a copy of the Report
would be saved on the Organisation’s system as a PDF file. It claimed that the Report
was dynamically generated by the Web Application and presented for viewing, without
storing a copy on the Website. However, when the operation of the Web Application
was demonstrated to it, the Organisation agreed that the Reports could have been
created but disclaimed knowledge of this. It also maintained that the data should have
been removed from the server when that particular version of the Web Application was
discontinued in 2010. In this regard, the Organisation’s explanation was that “[the Web
Application] and all its data should have been removed, but I am not sure if [the Web
Application] is still in the server”.

In relation to how the Reports became publicly accessible, the Organisation’s version
of events is that the webpages containing the Reports (the “Webpages”) were
inadvertently created on or around February 2017 during the redesign of the
Organisation’s Website. The Organisation had engaged an independent developer (the
“Developer”) to redesign its Website by changing it from HTML to WordPress. The
Developer provided a test URL to the Organisation to confirm that the Website was
designed according to the latter’s instructions. The Organisation did so, but did not
detect that the Webpages had been created. According to the Organisation, during the
redesign process, password protection for the Reports was not implemented even
though this was implemented previously. On balance, the Organisation is given the
benefit of doubt and its position that the Reports were made publicly accessible as a
result of the redesign is accepted. The complaint to the Commission (on 10 July 2017),
was submitted not long after the redesigning of the Website in or around February 2017,
and to the Commission’s knowledge, there had not been any complaints prior to this. If
the earlier version of the Website did not implement any form of access control, any
one of the employees of the Organisation’s clients who had used the system would
likely have raised this as an issue and the Organisation would have had to rectify it.

At the time of the Incident, the webpages contained Reports relating to 671 employees
of the Organisation’s clients (the “Affected Individuals”). Depending on the type of
Report, the information therein (collectively, “Personal Data”) may have included:
(a)

the names of the Affected Individuals;

(b)

the name and addresses of the Affected Individuals’ employers;

(c)

appraisals of the Affected Individuals’ work performance by subordinates,

supervisors and/or peers;
(d)

the Affected Individuals’ 360 Feedback scores; and

(e)

an indication of whether the Affected Individuals were top performers within

their respective organisations.

Remedial Measures
8

Upon being notified of the Incident by the Commission, the Organisation undertook the
following remedial actions:
(a)

moved the Reports to password-protected locations and subsequently deleted

Reports prepared for former clients;
(b)

requested the service provider hosting the Website (the “Webhost”) to provide

the Organisation with the access logs for the Webpages;
(c)

engaged a developer to scan the Website and find out whether there were more

webpages containing Reports which were accessible through the Internet without any
access restrictions; and
(d)

requested the Webhost to conduct an audit of all web based applications and

introduce enhanced security monitoring to prevent any lapses.
Findings and Basis for Determination
Whether the Organisation had breached section 24 of the PDPA
9

Section 24 of the Personal Data Protection Act 2012 (“PDPA”) requires organisations
to protect personal data in their possession or under their control by making reasonable
security arrangements to prevent unauthorised access, collection, use, disclosure,
copying, modification, disposal or similar risks. Although the Organisation had
engaged the Developer to redesign the Website, the Developer did not process any
personal data on behalf of the Organisation. The Organisation managed the Website on
its own and retained full responsibility for the IT security of the Website and the
Personal Data.

First, as stated in paragraph 5 above, the Organisation demonstrated a lack of
knowledge as to the security arrangements of its Website, in particular, the creation and
storage of the Reports, and had been under the mistaken impression that the Personal
Data had been removed from the server when the previous Website was discontinued.
In order to fulfil its Protection Obligation, the Organisation is required to, at the very
5

least, be aware of how and where it stores personal data in order to implement measures
to protect such data. In this regard, the Guide on Building Websites for SMEs (revised
10 July 2018) states that:
“5.7 Personal Data Inventory
5.7.1 Organisations and any engaged IT vendors should keep track of where the collected
personal data is stored, and should impose a limit on how long the data is kept, or regularly
review their need to continue storing the personal data.
5.7.2 If the personal data is no longer required, organisations and any engaged IT vendors should
then ensure that the personal data is anonymised or disposed of in such a way that it cannot be
recovered.”
[Emphasis added.]

Secondly, the Organisation did not give any specific instructions to the Developer to
protect personal data or on security arrangements of its Website during the redesign
process. The engagement was done over a short email exchange, and the Organisation
could not produce the contract or evidence of any written instructions to the Developer
on security arrangements. It had relied solely on the goodwill and integrity of the
Developer to conduct the redesign properly, without any documentation, supervision or
other means of control.

While the Organisation claimed that the Developer was engaged to merely change the
“look and feel” of the Website, the facts suggest that the redesign of the Website was a
more involved project which required a significant amount of coding work and
amounted to building a new Website. In this regard, the Developer had expressly
informed the Organisation that the scope of work involved the need to redesign the
Website on the WordPress environment instead of using the HTML coding of the
existing Website and required the existing content on the Website to be migrated. This
is not merely a redesign of the look-and-feel of the Website, but a redevelopment. Thus,
the Organisation should have provided the Developer with clear instructions to ensure
that no personal data was subject to unauthorised disclosure or access as a result of the
redesign.

According to the Guide on Building Websites for SMEs (at [4.2]):
“4.2.1 Organisations should emphasise the need for personal data protection to their IT
vendors, by making it part of their contractual terms. The contract should also state clearly the
responsibilities of the IT vendor with respect to the PDPA. When discussing the scope of the
outsourced work, organisations should consider whether the IT vendor’s scope of work will
include any of the following:


Requiring that IT vendors consider how the personal data should be handled as part
of the design and layout of the website.



Planning and developing the website in a way that ensures that it does not contain
any web application vulnerabilities that could expose the personal data of
individuals collected, stored or accessed via the website through the Internet.

…”
[Emphasis added.]

The Commission has also taken a similar position in Re Tutor City [2019] SGPDPC 5,
in which the organisation was unaware of its obligations under the PDPA and showed
a lack of knowledge of the security arrangements over its website. Specifically, the
organisation in that case did not, inter alia, communicate any specific security
requirements to its developer to protect the personal data stored on the website’s server
(including ensuring that the personal data would not be accessible to the public).

Thirdly, the Organisation failed to conduct vulnerability scans or any other form of
security testing for the Website. As set out in the Guide on Building Websites for SMEs
(at [5.6]):
“5.6 Security Testing
5.6.1 Testing the website for security vulnerabilities is an important aspect of ensuring the
security of the website. Penetration testing or vulnerability assessments should be conducted
prior to making the website accessible to the public, as well as on a periodical basis (e.g.
annually). Any discovered vulnerabilities should be reviewed and promptly fixed to prevent
data breaches.

5.6.2 Where organisations have outsourced the development of its website, they should either
require the IT vendor(s) to conduct the above security testing, or arrange for a cybersecurity
vendor to do so. As a baseline, organisations may wish to consider using the Open Web
Application Security Project (OWASP) Testing Guide and the OWASP Application Security
Verification Standard (ASVS) to verify that security requirements for the website have been
met.”
[Emphasis added.]

In Re InfoCorp Technologies Pte Ltd [2019] SGPDPC 17, the Commission took the
view that the organisation’s failure to conduct web application vulnerability scans was
a breach of section 24 of the PDPA, and that given the sensitivity of the personal data
which the documents contained, it was unreasonable that the organisation had omitted
security testing prior to the launch of the website. Also, in Re WTS Automotive Services
Pte Ltd [2018] SGPDPC 26, the Commission emphasised the need for regular review
of security arrangements and tests to detect vulnerabilities, it stated (at [18]) that:
“… [t]he Commission also recognises that personal data of individuals may be exposed if the
website or database in which it is stored contains vulnerabilities. There needs to be a regular
review to ensure that the website collecting personal data and the electronic database storing
the personal data has reasonable security arrangements to prevent unauthorised access,
collection, use, disclosure, copying, modification, disposal or similar risks. The Commission
considers that it is good practice for an organisation to “conduct regular ICT security audits,
scans and tests to detect vulnerabilities…”
[Emphasis added.]

In this case, even if the Organisation was unaware that the Reports were being created
and stored, had the Organisation conducted vulnerability scans as a form of security
testing on its Website prior to the redesigned Website going live or at any time after
that, the fact that the folders contained Reports with personal data and the fact that the
Reports were publicly-accessible would likely have been detected and could have been
remedied. As a result, the Organisation was unable to assess whether the folders ought
to have been restricted. It also did not consider whether any webpages which were
created as part of the redesign of its Website were correctly created.

The foregoing lapses demonstrate a fundamental lack of care by the Organisation over
the personal data in its possession and/or under its control. It is clear that the
Organisation had not applied its mind to its obligations under section 24 of the PDPA
with respect to implementing adequate security arrangements to protect the Reports. In
view of the above, the Commissioner found the Organisation in breach of section 24 of
the PDPA.

Whether the Organisation had breached sections 11(3) and 12 of the PDPA
19

Section 11(3) of the PDPA requires organisations to designate one or more individuals,
typically referred to as the data protection officer (“DPO”) to be responsible for
ensuring the organisations’ compliance with the PDPA. Section 12 of the PDPA
requires organisations to, inter alia, develop and implement policies and practices that
are necessary for the organisation to meet its obligations under the PDPA (“Data
Protection Policies”), and to communicate information about such policies and
practices to its staff.

In the course of the Commission’s investigations, the Organisation admitted that it was
unaware of the data protection provisions of the PDPA and was under the impression
that the PDPA only relates to the Do-Not-Call provisions. Hence, the Organisation did
not appoint a DPO or develop and implement any Data Protection Policies. In this
regard, it is a trite principle of law that ignorance of the law is no excuse. Hence, the
Organisation’s lack of awareness of its obligations under the PDPA is not an excuse for
contravening the PDPA.

The Organisation also admitted that, at the time of the Incident, it only had certain
unwritten policies with respect to the protection of client data, which were
communicated to its employees. In this regard, it is important to reiterate that an
organisation’s Data Protection Policies should be documented in a written policy, as
per Re Furnituremart.sg [2017] SGPDPC 7 at [14]:
“[t]he lack of a written policy is a big drawback to the protection of personal data. Without
having a policy in writing, employees and staff would not have a reference for the
Organisation’s policies and practices which they are to follow in order to protect personal data.
Such policies and practices would be ineffective if passed on by word of mouth, and indeed, the

Organisation may run the risk of the policies and practices being passed on incorrectly. Having
a written policy is conducive to the conduct of internal training, which is a necessary component
of an internal data protection programme.”

In light of the foregoing, the Commissioner found that the Organisation had also
breached sections 11(3) and 12 of the PDPA.

Representations by the Organisation

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

amount of financial penalty that was to be imposed. The Organisation raised the following
factors for consideration:
(a)

The Commission should not have placed such significant weight on the Personal

Data in the Reports that was exposed in the Incident. In this regard, the Personal Data
in the Reports should not be accorded the status of sensitive personal data and treated
as an aggravating factor because:
(i)

The

Reports

did

not

contain

the

Affected

Individual’s

identification/NRIC number, health data or biometric data. The identifying
personal data was limited to the name of the Affected Individuals and the name
of his/her employer; and
(ii)

The feedback data in the Reports would not fall within the realm of what

would typically be known as sensitive personal data as defined in Articles 9 and
10 of the European General Data Protection Regulation (“GDPR”);
(b)

Any aggravating weight to be given to the disclosure of the Reports must be

reduced by the fact that evaluative purpose exception in the PDPA permits a prospective
employer to obtain such feedback or evaluative information without consent of the
Affected Individuals. The Organisation posited that the evaluative purpose exception
tempers the extent of breach or application of the Protection Obligation because
disclosure is permitted so long as the exception applies;
(c)

The possibility of a member of the public specifically carrying out keyword

searches of the names of Affected Individuals during the period when the specific URL
links leading to the Reports had been exposed would not be high;
10

(d)

The Reports were not more recent than the year 2010. As the Incident occurred

in 2017, the accuracy of the contents of the Reports would have waned with the
effluxion of time, and this could be a point taken into consideration by a prospective
employer;
(e)

In past decisions, the Commission has taken into consideration the financial

circumstances of an organisation in determining the financial penalty (if any) to be
imposed. The financial penalty that the Commissioner intended to impose would have
a crushing burden on the Organisation, and cause undue hardship. Further, taking into
consideration the type of personal data and the potential harm to the Affected
Individuals, the proposed financial penalty would be disproportionately higher than
what had been imposed on organisations in previous decisions; and
(f)

The Incident was a one-off occurrence and there was no evidence that the

Website was otherwise insecure. During the past 16 over years that the Organisation
has been in business, there were no other complaints in relation to unauthorised
disclosure of personal data.
24

With respect to the Organisation’s representations on the nature of the Personal Data in
the Reports at [23(a)], Singapore’s legislative approach to determining the sensitivity
of personal data is different from jurisdictions like the European Union. Unlike the
GDPR, the PDPA does not have a definition of sensitive personal data. It is
inappropriate to draw comparisons with the GDPR approach to defining sensitivity of
personal data as the jurisprudential basis of GDPR is markedly different from the PDPA.
The Commission’s approach in each case is to assess the nature of the personal data in
question, taking into account specific circumstances such as the context in which the
data was collected and the potential risk of harm due to unauthorised access or
disclosure.

The Organisation’s representations on the evaluative purpose exception at [23(b)]
cannot be accepted. The fact that personal data that may be collected, used or disclosed
under an exception to consent cannot ipso facto be equated with an inference that the
class of personal data is less sensitive and need not be protected, or that there is less
culpability for a failure to protect. It is necessary to examine the nature of the exception
and the raison d’etre for its existence. The following analysis is confined to the
11

evaluative purpose and is not intended to establish any special rule for personal data
covered by other exceptions.
(a)

The PDPA recognises that there is a class of personal data that exists for an

evaluative purpose. A perusal of its definition discloses that the categories of activities
are characterised by the need for full disclosure and frank discussions in order to arrive
at a decision to, for example, employ, promote or dismiss a person, amongst a list of
other circumstances that circumscribe this purpose.1 The recognition of the need for
full disclosure and frank discussions is carried through in a number of exceptions,
which permit personal data to be collected, used and disclosed without consent. 2
Further, personal data in the nature of opinion data kept solely for an evaluative purpose
is exempted from the access and correction requirements. 3 The upshot of these
exceptions is to recognise the necessity to preserve the space for full disclosure of
relevant personal data and frank exchanges of views between persons who are tasked
to conduct an evaluation before making a decision or recommendations leading to a
decision.
(b)

Given the nature of the evaluative purpose exceptions and their raison d’etre, it

is necessary to ensure that organisations accord personal data that is covered by the
evaluative purpose exceptions with a higher degree of protection. The quid pro quo for
organisations having the liberty to collect, use and disclose personal data without
consent for evaluative purposes, and to keep opinion data beyond the reach of data
subjects for access and correction, is that they are expected to put in place more robust
measures to comply with the Protection Obligation. In other words, personal data that
is kept for an evaluative purpose should be treated as sensitive data and be protected to
a greater degree.

See definition of “evaluative purpose” in section 2 of the PDPA. See also Section 29(3) of New Zealand’s
Privacy Act 1993 which has a similar definition of “evaluative material” for the purposes of a refusal to disclose
personal information pursuant to Principle 6 (Access to personal information).
2
See para 1(f) of the Second Schedule, para 1(f) of the Third Schedule and para 1(h) of the Fourth Schedule of
the PDPA.
3
See para 1(a) of the Fifth Schedule and para 1(a) of the Sixth Schedule of the PDPA respectively. See also
Section 29(1)(b) of New Zealand’s Privacy Act 1993 which permits an agency to refuse to disclose personal
information pursuant to Principle 6 if (i) the disclosure of the information or of information identifying the
person who supplied it, being evaluative material, would breach an express or implied promise (i) which was
made to the person who supplied the information; and (ii) which was to the effect that the information or the
identity of the person who supplied it or both would be held in confidence.
1

(c)

Further, the Incident in the present case involved the risk of unauthorised

disclosure to the world at large whereas the evaluative purpose exception is much
narrower in scope (i.e. it permits disclosure of personal data without consent to specific
individual(s)/organisation(s) only where it is necessary for evaluative purposes). The
expectations of persons who provided the 360-degree feedback would have been for
their feedback to be accessed by persons with a role in evaluating the performance of
the employee under review. It would be difficult, by any stretch of imagination, for
them to accept that their feedback was accessible by the world at large.
26

The possibility of actual unauthorised disclosure raised by the Organisation at [23(c)]
had already been taken into consideration in determining the financial penalty that was
to be imposed. While the risk of actual unauthorised disclosure may have not been high,
the fact that the Reports were exposed to the risk of unauthorised access and disclosure
for more than 7 years (between 2009 to 2017) is particularly glaring.

As for the accuracy of the contents of the Reports at [23(d)], the passage of
approximately 7 years is unlikely to make a significant difference to the potential harm
suffered by the Affected Individuals due to unauthorised access or disclosure of the
Reports, or dampen the expectations of the persons who provided feedback as discussed
in [25(c)].

With respect to the Organisation’s representations comparing the present case to earlier
decisions at [23(e)], it needs only be said that each decision is based on the unique facts
of that case. The decision in each case takes into consideration the specific facts of the
case so as to ensure that the decision and direction(s) are fair and appropriate for that
particular organisation.

The fact that the Incident may have been the Organisation’s first data breach is not a
mitigating factor. Conversely, if the Incident was a repeated contravention by the
Organisation of the Protection Obligation, this would likely weigh in favour of a higher
financial penalty.

Having carefully considered the representations, the Commissioner has decided to
reduce the financial penalty to the amount set out at [33(a)]. The quantum of financial
penalty has been determined after due consideration of the appropriate weight to be
13

given to the aggravating factors at [32], the Organisation’s financial circumstances and
to avoid imposing a crushing burden on the Organisation. Although a lower financial
penalty has been imposed in this case, this is exceptional and should not be taken as
setting any precedent for future cases.
The Commissioner’s Directions
31

In determining the directions to be imposed on the Organisation under section 29 of the
PDPA, the Commissioner took into account, as a mitigating factor, the fact that the
Organisation had promptly taken the remedial measures set out above (at [8]).

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

the Personal Data in the Reports were sensitive in nature as they included data

on the assessment of the Affected Individuals’ work performance and unauthorised
access of such data could potentially result in harm to the individuals concerned (for
example, the individuals’ future employment prospects may be affected);
(b)

the Personal Data in the Reports was exposed to the risk of unauthorised access

and disclosure for a period of more than 7 years; and
(c)

the Organisation showed a lack of awareness of its obligations under the PDPA

even though it processes large volumes of sensitive personal data in the course of its
business.
33

Having carefully considered the facts and circumstances of this case and the above
mitigating and aggravating, the Commissioner hereby directs the Organisation:
(a)

To pay a financial penalty of $90,000 within 30 days of 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;
(b)

to appoint a DPO within 30 days from the date of this direction; and

(c)

to develop and implement policies and practices that are necessary for the

Organisation to meet its obligations under the PDPA, and communicate them to its
staff, within 30 days of the date of this direction.

YEONG ZEE KIN
DEPUTY COMMISSIONER
FOR COMMISSIONER FOR PERSONAL DATA PROTECTION

",Financial Penalty,6a21009555c09878fe1f590900953bc8f01d5acf
69,69,1,952,"A financial penalty of $9,000 was imposed on Iapps for failing to put in place reasonable security arrangements to prevent the unauthorised disclosure of personal data of some users of the ActiveSG mobile application.","[""Protection"", ""Financial Penalty"", ""Information and Communications"", ""Code deployment"", ""Wrong Environment""]",2021-03-11,https://www.pdpc.gov.sg/-/media/Files/PDPC/PDF-Files/Commissions-Decisions/Decision---Iapps-Pte-Ltd---10022021.pdf,Protection,Breach of the Protection Obligation by Iapps,https://www.pdpc.gov.sg/all-commissions-decisions/2021/03/breach-of-the-protection-obligation-by-iapps,2021-03-11,"PERSONAL DATA PROTECTION COMMISSION

[2021] SGPDPC 1
Case No DP-1903-B3441

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

DECISION

Iapps Pte Ltd
[2021] SGPDPC 1
Lew Chuen Hong, Commissioner — Case No DP-1903-B3441
10 February 2021
Introduction
1

On 1 March 2019, the Personal Data Protection Commission (the

“Commission”) received a complaint from an individual (the “Complainant”)
in relation to potential unauthorised disclosure of his personal data through the
ActiveSG mobile application (the “ActiveSG App”). The Complainant’s
concerns arose because he was able to view another individual’s personal data
when he logged into his child’s supplementary account on the ActiveSG App
(the “Incident”)
Facts of the Case
2

ActiveSG is a national movement for sports coordinated by Sport

Singapore,1 a statutory board of the Ministry of Culture, Community and Youth.
Iapps Pte Ltd (the “Organisation”) is a financial technology company
specialising in mobile application development and marketing. Sport Singapore
engaged the Organisation to develop, deploy and operate the Super Sports Club
Membership Management System (“SSCMMS”). The functions of SSCMMS
included membership registration, and the ActiveSG App was a component of

Sport Singapore was formerly known as Singapore Sports Council.

Iapps Pte Ltd

[2020] SGPDPC 1

the SSCMMS. Members of ActiveSG could use the ActiveSG App to book sport
facilities, register for fitness classes and purchase entry passes to ActiveSG
sport centres.
3

Sport Singapore is the owner of the SSCMMS and ActiveSG App.

Pursuant to the written contract between the Organisation and Sport Singapore,
the Organisation’s scope of work included providing and operating the
production server for the ActiveSG app. The Organisation also developed,
deployed and operated the SSCMMS (including the ActiveSG App).
4

On 1 March 2019, the Organisation’s engineer developed a security code

fix for the ActiveSG App. The security code fix was meant to be deployed into
the enterprise environment (which was a test environment) for further testing.
However, due to human error, the security code fix was deployed into the
production environment, resulting in the Incident.
5

According to the Organisation, the personal data of 153 individuals (the

“At Risk Individuals”) had been at risk of unauthorised access by 84
individuals during the Incident. Out of the At Risk Individuals, there was actual
unauthorised access of 108 individuals’ (including 9 minors below the age of
18) (the “Affected Individuals”) names and NRIC numbers (“Disclosed
Data”) by 84 individuals who were able to view this information when logging
into their own accounts on the ActiveSG App. For 6 of the Affected Individuals,
in addition to the Disclosed Data, there was also actual unauthorised access of
additional personal data, including (collectively, the “Additional Disclosed
Data”):
(a)

Email address;

(b)

Mobile telephone number;

Iapps Pte Ltd

[2020] SGPDPC 1

(c)

Home telephone number;

(d)

Address;

(e)

Gender;

(f)

Date of birth;

(g)

Race;

(h)

Employment status; and

(i)

Sports Interests.

Upon being notified of the Incident on the same day, the Organisation

immediately took the following remedial actions:
(a)

Rectified the issue within 2 hours of the Incident;

(b)

Reminded its staff to be careful and vigilant in the course of their

work; and
(c)

Together with Sport Singapore, implemented the following

measures:
(i)

Separated the enterprise environment and production

environment that were previously on the same server;
(ii)

Put

place

2-factor

authentication

for

the

Organisation’s engineers to access the production environment.
This means that the engineers are required to obtain the 2-factor
one-time password from Sport Singapore to access the
production environment;

Iapps Pte Ltd

[2020] SGPDPC 1

(iii)

Monitoring of affected users for suspicious activities;

and
(iv)
7

Implemented dynamic QR codes for member IDs.

Sport Singapore also notified the Affected Individuals about the

Incident.
The Commissioner’s Findings and Basis for Determination
8

There is the preliminary issue of whether the Organisation was a data

intermediary for Sport Singapore, and whether it could avail itself of the
exception under the previous section 4(1)(c) of the of the Personal Data
Protection Act 2012 (“PDPA”).2
9

Effective 1 February 2021, the exclusion in section 4(1)(c) of the PDPA

has been amended to be limited to “public agencies” only. Organisations acting
on behalf of public agencies in relation to the collection, use or disclosure of
public data (even when in an agency relationship of the type described below),
are now subject to obligations under the PDPA, and cannot claim to be excluded
from the same.
10

As the Incident in this case occurred prior to 1 February 2021, the

applicability of the exclusion under the previous section 4(1)(c) of the PDPA
remains to be considered. However, the Commission makes clear that this
exclusion will not be applicable or considered in future cases.

Prior to 1 February 2021, section 4(1)(c) of the PDPA provided that “any public agency or an
organisation in the course of acting on behalf of a public agency in relation to the collection,
use or disclosure of personal data is not subject to the obligations under Parts III to VI of the
PDPA”
2

Iapps Pte Ltd

[2020] SGPDPC 1

The exclusion in the previous section 4(1)(c) of the PDPA for

organisations acting on behalf of public agencies was based on the legal concept
of agency i.e. where the organisation was authorised by a public agency to act
in its place, as its agent, and the agent manifested assent or otherwise consented
to so act.3 Whether an agency relationship was created in any particular case is
essentially a question of fact. Relevant factors to take into consideration when
determining whether an agency relationship arose included the communications
between the parties and their conduct, as well as the terms of any relevant
contract.
12

The underlying question in each case was whether the organisation was

authorised to act on behalf of the principal. The authorisation by the principal
in an agency relationship is usually made expressly, although it could in some
cases be by implication from the conduct or situation of the parties. Where there
is such authority, the acts of the agent that are within the scope of the authority
are the acts of the principal, which would be legally liable for the acts of its
agent.4
13

In the present case, the Commission’s investigations revealed that the

Organisation was at all material times an independent third party vendor. There
was nothing in the contract between the parties which expressly authorised the
Organisation to act on behalf of Sport Singapore. The clauses in the contract
pointed to the Organisation being a service provider to Sport Singapore, and not
its agent. Further, there was an indemnity clause in the contract which obliged
the Organisation to among others, indemnify and keep Sport Singapore fully

See Alwie Handoyo v Tjong Very Sumitomo and anor [2013] 4 SLR 308 at [147]

See Ong Han Ling and anor v American International Assurance Co Ltd and ors [2018] 5
SLR 549 at [208]

Iapps Pte Ltd

[2020] SGPDPC 1

indemnified against all actions, claims, demands, losses, expenses arising out of
or in connection with the performance of the contract by the Organisation. As
explained at [11] – [12], if the Organisation and Sport Singapore were in an
agency relationship, acts of the agent (i.e. the Organisation) within the scope of
authority would be acts of the principal (i.e. Sport Singapore) who would be
legally liable for acts of its agent. An indemnity would therefore not be
necessary. The presence of the indemnity clause is evidence that the relationship
was not a principal-agent relationship. In addition, Sport Singapore confirmed
that it had never appointed the Organisation to act in its place. In the
circumstances, the exclusion in the previous section 4(1)(c) of the PDPA did
not apply to the Organisation.
14

With respect to whether the Organisation was acting as a data

intermediary, the Commission’s investigations found that the Organisation was
engaged to carry out activities of “processing” personal data on behalf of Sport
Singapore as defined in section 2(1) of the PDPA. As mentioned at [3], the
Organisation’s scope of work included developing, deploying and operating the
SSCMMS (including the ActiveSG App). In the course of operating the
SSCMMS and the ActiveSG App, the Organisation organised and retrieved the
Disclosed Data and the Additional Disclosed Data on the behalf of Sport
Singapore. In addition, the Organisation also processed service requests (which
included enquiries and extraction of information including the Disclosed Data
and Additional Disclosed Data) on behalf of Sport Singapore. The Organisation
was therefore acting as a data intermediary of Sport Singapore
Whether the Organisation had contravened section 24 of the PDPA
15

Section 24 of the PDPA provides that an organisation shall protect

personal data in its possession or under its control by making reasonable

Iapps Pte Ltd

[2020] SGPDPC 1

security arrangements to prevent unauthorised access, collection, use,
disclosure, copying, modification or similar risks.
16

The obligation to make reasonable security arrangements does not attach

unless an organisation was in possession or control of personal data. In the
present case, the Organisation provided the production environment and
operated the SSCMMS (including the ActiveSG App). The Organisation
therefore had actual possession of the Disclosed Data and Additional Disclosed
Data and control of the processing activities that they had contracted to provide.
Therefore, prior to the Incident, they were obliged to put in place reasonable
security arrangements to protect the Disclosed Data and Additional Disclosed
Data.
17

The Commission’s investigations revealed that the Organisation’s

processes for the deployment of code into production and test environments
were not sufficiently robust to safeguard against risks of deployment of codes
into the wrong environment.
(a)

According to the Organisation, its usual code deployment

process went through 3 stages (i) User Acceptance Testing (“UAT”);
(ii) “enterprise environment” (i.e. test environment); and (iii) production
environment.
(b)

Due to human error on the part of its engineer, the Organisation’s

processes and procedures for the deployment of the security code fix
into the ActiveSG App were not followed. After the UAT was
completed, the code that was meant to be deployed to the testing
environment was instead deployed directly into the production
environment. This is a grave and serious error with, as is evident in this
case, potentially severe consequences. In this regard, the Commission’s
7

Iapps Pte Ltd

[2020] SGPDPC 1

investigations revealed that the Organisation did not have second-level
approvals or supervisory checks in its processes for the deployment of
codes into the test environment. This meant there was no oversight of
the code deployment process nor any supervision of the actions of the
Organisation’s engineers after UAT was completed.
(c)

As stated in the Commission’s previous decisions, relying solely

on employees to perform their duties diligently is not a sufficient
reasonable security arrangement – organisations should take practical
steps to implement its policies and procedures to protect personal data,
including identifying areas of high risk that require higher level of
approval and adequate supervision.5 In the present case, the deployment
of the security code fix into the ActiveSG App could potentially expose
the Disclosed Data and the Additional Disclosed Data to security risks.
The Organisation should have identified this risk, and implemented a
second-level check to ensure that its engineers deployed the codes into
the correct environment. Alternatively, the Organisation could have
automated its processes by using development operations software that
would automate the correct deployment of code.
(d)

The absence of any second-level checks in the Organisation’s

processes for the deployment of codes and lack of any other form of
security arrangement to safeguard against risks of deployment of codes
into the wrong environment amounted to weak internal work process
controls.

See Re Aviva Ltd [2017] SGPDPC 14 and Re Marshall Cavendish Education Pte Ltd [2019]
SGPDPC 34

Iapps Pte Ltd

[2020] SGPDPC 1

For the reasons above, the Commissioner found the Organisation in

breach of section 24 of the PDPA.
19

After being notified of the Commission’s proposed decision including

the proposed financial penalty amount, the Organisation made representations
to the Commission suggesting that (i) the Organisation had done the necessary
to comply with section 24 of the PDPA, or (ii) that a warning ought to be
administered in lieu of the Commission’s proposed financial penalty. The
Organisation’s representations were rejected for the following reasons:
(a)

The Organisation contended that it did have second-level checks

for the deployment of code, and referred the Commission to its Standard
Operating Procedure (“SOP”) for the SSCMMS. While the SOP did
describe multi-level checks at the UAT stage (i.e. the first stage of
testing), it not dictate any second-level checks relating to the deployment
of code into the enterprise environment, and thereafter production
environment (i.e. the second and third stages). In fact, the SOP contained
no references to deployment of code in the enterprise environment at all.
The Organisation failed to provide any evidence of any second-level
checks after UAT and before deployment of the code in production.
(b)

The Organisation claimed that the Incident was the result of

human error which happened “in the rush of the moment” and would not
have been prevented by a second level check. The Commission
disagrees. For the reasons stated at 17(c) and 17(d) above, the
appropriate processes such as a second-level check or automated code
deployment via software should have been implemented, and would
have prevented the Incident. Such processes are all the more necessary

Iapps Pte Ltd

[2020] SGPDPC 1

considering the time pressure that engineers often operate under, as
appears to have happened in this case.
(c)

The Organisation highlighted that it had taken prompt remedial

actions after discovery of the Incident (listed at [6] above). The
Commission accepts that the remedial action taken by the Organisation
was timely and sufficient. This has been taken this into consideration in
quantifying the financial penalty imposed in this case (as set out below),
and in deciding that no further directions need be issued to the
Organisation.
Financial Penalty
20

In determining whether to impose a financial penalty on the

Organisation pursuant to section 48J(1) of the PDPA, and if so, the amount of
such financial penalty, the Commissioner took into account the factors listed at
section 48(6) of the PDPA, including that:
(a)

that the Disclosed Data included the NRIC numbers of 9 minors;

(b)

The

Organisation

cooperated

with

the

Commission’s

investigations; and
(c)

The Organisation implemented prompt remedial actions (i.e. the

issue was fixed within 2 hours of the Incident).
21

On 23 July 2020, the Organisation was given notice of the

Commission’s intention to impose a financial penalty of S$11,000 and was
invited to make representations. Having considered the Organisation’s
representations dated 21 August 2020, 21 October 2020, and 29 October 2020,

Iapps Pte Ltd

[2020] SGPDPC 1

as well as all the relevant factors of this case, the Commissioner hereby requires
the Organisation to:
(a)

pay a financial penalty of S$9,000 within 30 days from the date

of the notice accompanying this decision, 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 the financial penalty
until it is paid in full.

YEONG ZEE KIN
DEPUTY COMMISSIONER
FOR COMMISSIONER FOR PERSONAL DATA PROTECTION

",Financial Penalty,254f6fd787bbfaed69d1c08e1395d0e7cc753f16
70,70,1,952,"A financial penalty of $5,000 was imposed on BLS International Services Singapore for failing to put in place reasonable security arrangements to prevent the unauthorised disclosure of the personal data of individuals who had submitted a booking for an appointment on its website.","[""Protection"", ""Financial Penalty"", ""Information and Communications"", ""Inadequate scoping of testing"", ""URL manipulation""]",2021-01-14,"https://www.pdpc.gov.sg/-/media/Files/PDPC/PDF-Files/Commissions-Decisions/Decision---BLS-International-Services-Singapore-Pte,-d-,-Ltd,-d-,-30112020-(003).pdf",Protection,Breach of the Protection Obligation by BLS International Services Singapore,https://www.pdpc.gov.sg/all-commissions-decisions/2021/01/breach-of-the-protection-obligation-by-bls-international-services-singapore,2021-01-14,"PERSONAL DATA PROTECTION COMMISSION
Case No. DP-2007-B6563
In the matter of an investigation under section 50(1) of the
Personal Data Protection Act 2012
And
BLS International Services Singapore Pte. Ltd.

SUMMARY OF THE DECISION
1. BLS International Services Singapore Pte. Ltd. (the “Organisation”) provides
government-to-citizen services for the High Commission of India in Singapore, such as
visa and consular services.

2. On 7 July 2020, the Personal Data Protection Commission (the “Commission”) received
information that the URLs of the printable version of appointment booking confirmation
webpages could be manipulated to access other individuals’ personal data (the “Incident”).
The personal data comprised the individual’s name, passport number, contact number,
email address, type of service request, booking date/time, appointment date/time, and
number of booking applications.

3. The Organisation subsequently requested for this matter to be handled under the
Commission’s expedited breach decision procedure. In this regard, the Organisation
voluntarily provided and unequivocally admitted to the facts set out in this decision. It also

admitted that it was in breach of section 24 of the Personal Dara Protection Act (the
“PDPA”).

4. Investigations revealed that on 8 June 2020, which was about a month prior to the Incident,
the Organisation had implemented a new booking system for the High Commission of
India. Under this new booking system, users who submitted a booking for an appointment
at the High Commission of India would be provided with an URL, which led to a printable
version of the booking confirmation. In designing the booking system, the Organisation
had intended for the URLs to be encrypted. This would have made it more difficult for
people to manipulate the URL. However, the encryption was not done properly due to a
coding error. Although the Organisation had conducted some testing on the new booking
system, the testing was not extensive enough to detect the error.

5. Upon realising the occurrence of the Incident from the Commission on 16 July 2020, the
Organisation took immediate action to investigate and subsequently identified the coding
error. On the same day, the Organisation made changes to the booking system. It stopped
providing users with an URL to a printable version of their booking confirmation. Instead,
the booking confirmation would be sent to the user’s email account.

6. The Organisation’s records showed that a total of 3,357 individuals used the new booking
system from 8 June 2020 to 16 July 2020. This meant that the personal data of 3,357
individuals was at risk of exposure by URL manipulation.

7. The Deputy Commissioner for Personal Data Protection found that the Organisation was
in breach of the Protection Obligation under section 24 of the Personal Data Protection Act
2012 for failing to conduct adequate testing of the booking system before it went “live”.
Depending on how the URL encryption was implemented, URL encryption could had been
a reasonable security measure for the personal data type the Organisation was collecting.
However, because the Organisation had not conducted adequate testing of the booking
system before it went “live”, the Organisation did not detect the coding error, thereby
resulting in the Incident.

8. After considering the circumstances of the case, including: (i) the Organisation’s upfront
voluntary admission of liability which significantly reduced the time and resources required
for investigations; and (ii) the Organisation’s prompt remedial actions, the Deputy
Commissioner for Personal Data Protection directs that the Organisation pays a financial
penalty of $5,000 for the breach.

9. The Organisation must make payment of the financial penalty 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 the financial
penalty until it is paid in full.

10. No further directions are required as the Organisation had taken actions to address the gaps
in its security arrangements.

",Financial Penalty,258d44ffd944015c9b8f9f9ffd545a6b10bb6fee
71,71,1,952,"A financial penalty of $9,000 was imposed on The Future of Cooking for failing to put in place reasonable security arrangements to prevent the unauthorised disclosure of its customers’ personal data on its website.","[""Protection"", ""Financial Penalty"", ""Wholesale and Retail Trade"", ""Data Intermediary"", ""Protection"", ""Security""]",2021-01-14,https://www.pdpc.gov.sg/-/media/Files/PDPC/PDF-Files/Commissions-Decisions/Decision---The-Future-of-Cooking-Pte-Ltd-20112020-(003).pdf,Protection,Breach of the Protection Obligation by The Future of Cooking,https://www.pdpc.gov.sg/all-commissions-decisions/2021/01/breach-of-the-protection-obligation-by-the-future-of-cooking,2021-01-14,"PERSONAL DATA PROTECTION COMMISSION
Case No. DP-2001-B5620
In the matter of an investigation under section 50(1) of the
Personal Data Protection Act 2012
And
The Future of Cooking Pte. Ltd.

SUMMARY OF THE DECISION
1. The Future of Cooking Pte. Ltd. (the “TFC”) operates an e-commerce website at
https://www.thermomix.com.sg (the “Website”), retailing kitchen appliances and
accessories.

2. On 3 January 2020, the Personal Data Protection Commission (the “Commission”)
received a complaint that a text file (the “File”) containing personal data was accessible via
the URL: https://thermomix.com.sg/wp-content/uploads/2019/10/woocommerce-orderexport-1.csv-1.txt. (the “Incident”).

3. The File contained the personal data of 178 unique individuals who had purchased items
from the Website. The File was accessible via the URL from 1 October 2019 until 6 January
2020. It contained the following types of personal data (the “Personal Data”):
a. Name;
b. Email Address;

c. Billing Address;
d. Shipping Address;
e. Customer Notes (e.g. delivery instructions);
f. Order information (such as payment status, mode of payment, and transaction ID);
g. Product ID of items;
h. Quantity of items ordered; and
i. Telephone number.

The Commission’s Findings
No breach by Hachi as a Data Intermediary
4. TFC had engaged Hachi Web Solutions Pte. Ltd. (“Hachi”) to re-design the Website and
also perform data backup and migration. Insofar as the data backup and migration activities
are concerned, Hachi was TFC’s data intermediary. The cause of the breach, however, did
not relate to the data processing activities but to the Website re-design. Therefore, Hachi
was not in breach of the Protection Obligation under section 24 of the Personal Data
Protection Act 2012 (the “PDPA”) by virtue of its role as a data intermediary.

TFC in breach of the Protection Obligation
5. The cause of the data breach may be traced to a WordPress plugin (the “Plugin”) which
was installed on the Website. The Plugin contained a bug which caused the File to be
generated and uploaded on the Website’s directory folder. Although this was a temporary
file, it was accessible to the public via the URL.

6. TFC had used the Website to collect the personal data of individuals. At the time of the
Incident, TFC’s database contained personal data of approximately 3,500 individuals. To
discharge its Protection Obligation under section 24 of the PDPA, TFC needed to have put
in place reasonable security arrangements to protect the personal data collected.

7. In this case, investigations revealed that TFC had failed to discharge its obligations as data
controller when engaging Hachi to undertake data processing activities. First, TFC did not
specify any requirements for Hachi to implement any data protection measures to be
implemented in the Website, whether in its contract with Hachi or other project
documentation. Second, TFC did not conduct any pre-launch security testing (such as
vulnerability assessments) on the Website. Had security testing been conducted, TFC
would have been able to detect the presence of the publicly accessible temporary file, even
if it was unaware of the bug in the Plugin that caused it.

8. Once it knew about the Incident, TFC and Hachi removed the Plugin and disabled the
public’s access to the relevant directory folder. Hachi also contacted the developers of the
Plugin, who acknowledged the existence of the bug and fixed the bug in an updated version.
TFC subsequently engaged a vendor to perform penetration testing and other measures to
enhance the security of the Website.

9. The Deputy Commissioner found TFC in breach of the Protection Obligation under section
24 of the PDPA. After considering the circumstances of the Incident, including according
mitigatory weight to TFC’s cooperation with the Commission during investigations and the

remedial action taken by TFC after the Incident, the Deputy Commissioner directs TFC to
pay a financial penalty of $9,000 for its breach.

10. TFC must make payment of the financial penalty 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 the financial
penalty until it is paid in full.

11. No further directions are required as TFC had taken actions to address the gaps in its
security arrangements.

",Financial Penalty,7255b9fe4b2433c5774bed593dd6215b52226a70
72,72,1,952,Singapore Technologies Engineering was found not in breach of the PDPA in relation to the transfer of the personal data of its Singapore-based employees to its subsidiaries based in United States.,"[""Transfer Limitation"", ""Not in Breach"", ""Manufacturing"", ""Ransomware""]",2021-01-14,https://www.pdpc.gov.sg/-/media/Files/PDPC/PDF-Files/Commissions-Decisions/Decision----ST-Engineering-Ltd---16112020.pdf,Transfer Limitation,No Breach of the Transfer Limitation Obligation by Singapore Technologies Engineering,https://www.pdpc.gov.sg/all-commissions-decisions/2021/01/no-breach-of-the-transfer-limitation-obligation-by-singapore-technologies-engineering,2021-01-14,"PERSONAL DATA PROTECTION COMMISSION

[2020] SGPDPC 21
Case No. DP-2006-B6426

In the matter of an investigation under section 50(1)
of the Personal Data Protection Act 2012
And
Singapore Technologies Engineering Limited
… Organisation

DECISION

Singapore Technologies Engineering Limited

[2020] SGPDPC 21

Singapore Technologies Engineering Limited
[2020] SGPDPC 21
Yeong Zee Kin, Deputy Commissioner — Case No. DP-2006-B6426
16 November 2020
Introduction
1

On 10 June 2020, Singapore Technologies Engineering Limited (the

“Organisation”) notified the Personal Data Protection Commission (the
“Commission”) that its subsidiary based in the United States of America
(“USA”), VT San Antonio Aerospace Inc. (“VT SAA”), had discovered a
cybersecurity incident where threat actors gained unauthorised access to VT
SAA’s US-based IT network and deployed a ransomware attack (the
“Incident”).
Facts of the Case
2

The Organisation is a Singapore incorporated company with a network

of subsidiaries in Asia, Europe, USA and the Middle East. The ransomware
attack was isolated to a limited part of VT SAA’s network, but also affected a
few of the Organisation’s subsidiaries based in the USA that were using IT
shared services provided by VT SAA. The Organisation’s IT network in
Singapore was not compromised during the Incident. However, the following
types of personal data belonging to 287 individuals in Singapore (“Affected

Singapore Technologies Engineering Limited

[2020] SGPDPC 21

Individuals”) were potentially exposed to the risk of unauthorised access
(collectively, the “Personal Data Sets”)1:
(a)

Name;

(b)

Address;

(c)

Email address;

(d)

Telephone number;

(e)

NRIC number and date of issue;

(f)

Passport details;

(g)

Photograph;

(h)

Date of birth;

(i)

Citizenship;

(j)

Country of residence;

(k)

Place of birth;

(l)

USA Social Security number;

(m)

USA visa information;

(n)

Details regarding government or military service, where applicable;

(o)

CV information;

(p)

Foreign identification numbers;

(q)

Government issued identification (ID) information;

This list sets out the personal data types potentially affected in the Incident. Not all of these
types of personal data were affected for each Affected Individual, and the type(s) of personal
data affected for each Affected Individual varies. The Personal Data Sets of 49 Affected
Individuals were assessed to have been “likely exfiltrated”, with the remaining Personal Data
Sets were assessed to have been “likely affected, may have been exfiltrated”.

Singapore Technologies Engineering Limited

[2020] SGPDPC 21

(r)

Associated information about minors; and

(s)

Employee status.

In this regard, the Affected Individual’s Personal Data Sets had been

transferred from the Organisation (in Singapore) to VT SAA and the
Organisation’s other subsidiaries (based in the USA). The purposes of the
transfer included making regulatory filings with the USA authorities,
secondment or transfers of employment and security clearance in connection
with visits to facilities.
4

Upon discovery of the Incident, the Organisation and VT SAA

immediately took the following remedial actions:
VT SAA
(a)

Notified the federal law enforcement officials in USA;

(b)

Immediately disconnected certain systems from the network and
retained leading third-party forensic advisors to investigate the Incident;

(c)

Conducted a rigorous review of the Incident and its systems, including
deploying advance tools to remediate the intrusion and to restore the
affected systems;

(d)

Strengthened its overall cybersecurity architecture, including enhanced
endpoint security controls, additional network monitoring and other
security hardening measures; and

(e)

Implemented a Security Operations Centre to provide 24/7 monitoring,
detection and response capabilities.

Singapore Technologies Engineering Limited

[2020] SGPDPC 21

The Organisation
(f)

Reprioritised and accelerated its existing IT harmonisation plan
(including the enhancement and hardening of internal controls and
external program elements) for all its entities.

Findings and Basis for Determination
5

As a preliminary point, the data protection obligations in the Personal

Data Protection Act 2012 (“PDPA”) did not apply to VT SAA and the
Organisation’s other subsidiaries (based in the USA) with respect to the
Incident. This is because they did not carry out any activities in relation to the
collection, use or disclosure of the Affected Individual’s Personal Data Sets in
Singapore. The Commission will defer to the ongoing investigations by the US
federal law enforcement officials into VT SAA and the Organisation’s
subsidiaries based in the USA. The Commission’s investigations in the present
case focused on whether the Organisation’s transfer of the Affected Individual’s
Personal Data Sets from Singapore to the USA met the requirements under the
PDPA.
The Transfer Limitation Obligation under Section 26 of the PDPA
6

Section 26(1) of the PDPA provides that an organisation shall not

transfer any personal data to a country or territory outside Singapore except in
accordance with requirements prescribed under the PDPA to ensure that
organisations provide a standard of protection to personal data so transferred
that is comparable to the protection under the PDPA (the “Transfer Limitation
Obligation”). The relevant requirements are prescribed in Part III of the
Personal Data Protection Regulations 2014 (“PDPR”). In particular:

Singapore Technologies Engineering Limited

(a)

[2020] SGPDPC 21

Regulation 9(1)(b) of the PDPR requires an organisation that transfers
personal data to a country or territory outside of Singapore to take
appropriate steps to ensure that the recipient of personal data is bound
by legally enforceable obligations (in accordance with Regulation 10) to
provide to the transferred personal data a standard of protection that is
at least comparable to that under the PDPA;

(b)

Regulation 10(1)(c) of the PDPR provides that such legally enforceable
obligations include, amongst other things, any binding corporate rules
in accordance with Regulation 10(3) of the PDPR; and

(c)

Regulation 10(3) of the PDPR provides that such binding corporate rules
must require every recipient of the transferred personal data to provide
a standard of protection for the transferred personal data that is
comparable to that of the PDPA, and must specify (i) the recipients of
the transferred personal data to which the binding corporate rules apply;
(ii) the countries and territories to which the personal data may be
transferred under the binding corporate rules; and (iii) the rights and
obligations provided by the binding corporate rules. Further such
binding corporate rules may only be used by recipients that are related
to the transferring organisation.

Whether the Organisation complied with the Transfer Limitation Obligation
7

The Commission’s investigations revealed that the Organisation had

complied with the Transfer Limitation Obligation for the reasons explained
below.
8

At the material time, the Organisation had put in place binding corporate

rules set out in the St Engineering’s Group Binding Corporate Rules for

Singapore Technologies Engineering Limited

[2020] SGPDPC 21

Transfers of Personal Data (PDP-04) (“BCRs”), which met the requirements of
Regulation 9(1)(b) read together with Regulations 10(1)(c) and 10(3) of the
PDPR:
(a)

The BCRs were applicable to and legally binding upon all of the
Organisation’s direct and indirect subsidiaries worldwide (each a
“Group Company” and collectively, the “Group”), concerning the
transfers (including international transfers) of personal data within the
Group;

(b)

The BCRs specified the countries and territories to which personal data
may be transferred (which included the USA);

(c)

Each Group Company that received transferred personal data was bound
by legally enforceable obligations to provide a standard of protection for
the personal data transferred that is at least comparable to the protection
under the PDPA. In particular:
“5.6

The Receiving Company shall protect the transferred 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 other similar risks to the
transferred Personal Data.

6.1

Each Group Company warrants and undertakes that it has

implemented and maintained appropriate security, technological and
organisational measures in accordance with the Group Company’s
legal obligations under the PDPA or other applicable Data Protection
Laws to protect Personal Data and to prevent unauthorised access,

Singapore Technologies Engineering Limited

[2020] SGPDPC 21

collection, use, disclosure, copying, modification, disposal or other
similar risks to the transferred Personal Data.”
(d)

Rights and obligations provided by the BCRs are specified. These
included the permitted purposes for transfer of personal data, data
protection obligations of the receiving company, and protection and
security of personal data. The permitted purposes set out in the following
clauses in the BCRs included the purposes of transfer of the Affected
Individual’s Personal Data Sets at [3]
“1.

Managing or terminating the employment relationship …

… (xvii) Preparing and making travel arrangements for employees’
work or business travel (including visa applications, transport and
accommodation arrangements) …
… 2.

Evaluative purposes …

… (iii) Evaluation for secondment / transfer of employment to another
entity within the Group / for extension of contract (for contract staff) /
termination / redundancy / restructuring …
… 3.

Group’s business operations, including the Group’s internal

business management, administration and operations: …
… (vi) Submission to government agencies and authorities for permits
and approvals …
… (xiii) To facilitate security clearance / entry access into premises of
customers, vendors, consultants and other business partners”.
9

Having carefully considered all the relevant circumstances and for the

reasons set out above, I find that the Organisation complied with the Transfer

Singapore Technologies Engineering Limited

[2020] SGPDPC 21

Limitation Obligation in relation to its transfer of the Affected Individual’s
Personal Data Sets to VT SAA and its other subsidiaries based in the USA.

YEONG ZEE KIN
DEPUTY COMMISSIONER
FOR PERSONAL DATA PROTECTION

",Not in Breach,e80b77152c3052ff0a5870f8773669cd59a36872
73,73,1,952,A warning was issued to Water + Plants Lab for failing to put in place reasonable security arrangements to protect the personal data of its employees. The incident resulted in the personal data being subjected to a ransomware attack.,"[""Protection"", ""Warning"", ""Scientific and Technical"", ""Ransomware"", ""No Security Arrangements"", ""No Patching""]",2020-12-18,https://www.pdpc.gov.sg/-/media/Files/PDPC/PDF-Files/Commissions-Decisions/Decision--Water--Plants-Lab-Pte-Ltd--181120.pdf,Protection,Breach of the Protection Obligation by Water + Plants Lab,https://www.pdpc.gov.sg/all-commissions-decisions/2020/12/breach-of-the-protection-obligation-by-water--plants-lab,2020-12-18,"PERSONAL DATA PROTECTION COMMISSION
Case No. DP-2004-B6182

In the matter of an investigation under section 50(1) of the
Personal Data Protection Act 2012
And
Water + Plants Lab Pte. Ltd.

SUMMARY OF THE DECISION

On 9 April 2020, Water + Plants Lab Pte. Ltd. (the “Organisation”) informed the
Personal Data Protection Commission of a ransomware infection that rendered the
Organisation’s server (the “Server”) inaccessible to the Organisation (the “Incident”).

The Incident occurred on or around 30 March 2020. Personal data of 28 employees were
encrypted by the ransomware. The personal data affected included the employees’ name,
NRIC/FIN/Work Permit number, address, date of birth, mobile number and photograph.

Investigations revealed that an employee from the Organisation had downloaded and
opened an email attachment that contained ransomware. At the time of the Incident, the
Organisation had some security measures in place, for example, it had anti-virus
protection, and access rights and password control for the Server. It also had a good
practice of performing regular backup of its Server, and most of the data was successfully

restored from an external backup. The Organisation therefore suffered minimal data loss
as a result of the Incident.

However, as admitted by the Organisation, it had not carried out any patching and
security scanning of the Server in the 12 months preceding the Incident. Patching and
regular security scanning are important security measures to prevent vulnerabilities in an
organisation’s ICT systems which a hacker may exploit in compromising personal data.
For this reason, the Deputy Commissioner for Personal Data Protection found that the
Organisation had failed to protect the personal data in its possession or under its control,
in breach of section 24 of the Personal Data Protection Act 2012.

Following the Incident, the Organisation installed a firewall with greater capabilities to
protect the Organisation against external threats, for example, possessing deeper content
inspection capabilities to identify malware. The Organisation had also conducted staff
training on personal data protection and on how to identify security threats.

Upon consideration of the facts, including the impact from the breach, the remediation
action taken by the Organisation and that there was no evidence of exfiltration of the data
in the Server, the Deputy Commissioner issued a warning to the Organisation.

",Warning,eee08e16b63cd4fae6c7d3775b36bf12d04f634d
74,74,1,952,A warning was issued to R.I.S.E Aerospace for failing to put in place reasonable security arrangements to protect the personal data of its employees from unauthorised disclosure. The incident resulted in the personal data being subjected to a ransomware attack.,"[""Protection"", ""Warning"", ""Manufacturing"", ""Ransomware"", ""No Security Arrangements"", ""IT security policies""]",2020-12-18,https://www.pdpc.gov.sg/-/media/Files/PDPC/PDF-Files/Commissions-Decisions/Decision---RISE-Aerospace-Pte-Ltd---131120.pdf,Protection,Breach of the Protection Obligation by R.I.S.E Aerospace,https://www.pdpc.gov.sg/all-commissions-decisions/2020/12/breach-of-the-protection-obligation-by-rise-aerospace,2020-12-18,"PERSONAL DATA PROTECTION COMMISSION
Case No. DP-2007-B6832
In the matter of an investigation under section 50(1) of the
Personal Data Protection Act 2012
And
R.I.S.E Aerospace Pte. Ltd.

SUMMARY OF THE DECISION

On 25 August 2020, R.I.S.E Aerospace Pte Ltd (the “Organisation”) notified

the

Personal Data Protection Commission (the “Commission”) of a ransomware infection
that had rendered its network storage server inaccessible to the Organisation (the
“Incident”).

The Incident occurred on or about 23 August 2020. Personal data of 21 employees were
encrypted by the ransomware. The personal data encrypted included the name, address,
contact number, NRIC number, Work Permit details, passport details. redacted bank
account numbers, and child’s date of birth.

Investigations revealed that the Organisation had not implemented adequate technical
security arrangements to protect the personal data in its possession or control, in
particular, the Organisation did not carry out any security scans or perform updates to
the server firmware despite being prompted to do so by the device manufacturer. In

addition, the Organisation did not put in place any documented form of IT Security
policies such as its password policy, policies for patching and updating of the company
server etc. These failings had resulted in a system that had vulnerabilities which a hacker
could exploit by injecting ransomware into the server.

Following the Incident, the Organisation had since discontinued the use of its network
storage server and to opt for cloud storage instead. Additionally, the Organisation also
decided to encrypt all its sensitive data and only store them on offline devices.

In the circumstances, the Deputy Commissioner for Personal Data Protection finds the
Organisation in breach of the Protection Obligation under section 24 of the Personal Data
Protection Act 2012 (the “PDPA”) and took into account the following factors in
deciding to issue a Warning to the Organisation.
a. The low number of affected individuals;
b. There was no evidence that the personal data affected in the Incident had been
misused in any form;
c. The Organisation had a backup copy of the encrypted personal data and did not lose
any personal data as a result of the Incident; and
d. The Organisation voluntary notified the Commission of the Incident.

In view of the remedial actions taken by the Organisation, the Commission will not be
issuing any other directions.

",Warning,1400daa426845ef3c61fb74391afd631da480958
75,75,1,952,"A financial penalty of $8,000 was imposed on Hello Travel for failing to put in place reasonable security arrangements to protect the personal data of its members from unauthorised disclosure.","[""Protection"", ""Financial Penalty"", ""Information and Communications"", ""Expedited"", ""Exploitation"", ""Vulnerability""]",2020-12-18,https://www.pdpc.gov.sg/-/media/Files/PDPC/PDF-Files/Commissions-Decisions/Decision---Hello-Travel-Pte-Ltd---301020.pdf,Protection,Breach of Protection Obligation by Hello Travel,https://www.pdpc.gov.sg/all-commissions-decisions/2020/12/breach-of-protection-obligation-by-hello-travel,2020-12-18,"PERSONAL DATA PROTECTION COMMISSION
Case No. DP-2004-B6189
In the matter of an investigation under section 50(1) of the
Personal Data Protection Act 2012
And
Hello Travel Pte. Ltd.

SUMMARY OF THE DECISION

On 8 April 2020, the Personal Data Protection Commission (the “Commission”)
received information that a database belonging to Hello Travel Pte Ltd (the
“Organisation”) was posted on an internet forum and was thus made publicly available
(the “Incident”).

The Organisation subsequently requested for this matter to be handled under the
Commission’s expedited breach decision procedure. In this regard, the Organisation
voluntarily provided and unequivocally admitted to the facts set out in this decision. It
also admitted that it was in breach of section 24 of the Personal Dara Protection Act (the
“PDPA”).

The compromised database contained the personal data of approximately 71,002 users
who had created accounts at the Organisation’s website (www.havehalalwilltravel.com)
from February 2015 to July 2018. The disclosed personal data included their name, email

address, date of birth, nationality and phone number. The table below summarises the
number of affected individuals for each corresponding type of personal data disclosed:
S/N

Type of Personal Data

Number of Individuals
Affected

Name

71,002

Email Address

57,693

Phone Number

453

Date of Birth

946

Nationality

20,754

The Organisation’s internal investigations pointed to a possible hack as the cause of the
Incident. Sometime in year 2018, the server instance which hosted the Organisation’s
website and the database became corrupted and unusable after the installation of a free
open source wordpress plugin. The Organisation believed that unknown parties could
have exploited vulnerabilities of the installed plugin at that time and exfiltrated the
database.

The Organisation admitted that it did not give due attention to personal data protection
and had neglected to put in place basic procedural and technical security arrangements
to protect the personal data in its possession and control. As examples, it did not have the
relevant policies and/or protocols in place to perform regular system patching or to
conduct security assessment and/or testing when making changes to its ICT systems.

Following the incident, the Organisation implemented technical measures to secure its
systems from potential vulnerabilities. The personal data of its members were also
encrypted immediately. Additionally, the Organisation had engaged relevant parties to
take down the compromised database and informed the affected individuals of the
Incident.

In determining the directions, if any, to be imposed on the Organisation. The Deputy
Commissioner took into account the following factors:

Aggravating factors
(a) The high number of individuals affected;
(b) The fact that personal data was exfiltrated and posted online; and
(c) The Organisation did not put in place basic procedural and technical security
arrangements.

Mitigating factors
(a) The Organisation had cooperated with the investigation;
(b) The Organisation’s upfront voluntary admission of liability to a breach of the
Protection Obligation under the PDPA;

(c) The Organisation’s prompt remedial actions at [7] to address the inadequacies in
its procedures and processes; and
(d) There was no evidence that the personal data affected in the Incident had been
misused in any form.

In the course of settling this decision, the Organisation made representation on the
amount of financial penalty which the Commission intends to impose and requested that
the financial penalty to be paid in instalments. The Organisation raised the following
factors for the Commission’s consideration:

(a) The Organisation had been suffering substantial loss due to the impact to the
travel industry by the Covid-19 pandemic; and
(b) The Organisation had already spent quite a substantial amount of money to fix
the security breach.

10.

Having carefully considered the representations, the Deputy Commissioner has decided
to reduce the financial penalty to the amount set out in [11a] and is agreeable for the
financial penalty to be payable in instalments. The quantum of financial penalty has been
calibrated after due consideration of the Organisation’s financial circumstances due to
the unprecedented challenges faced by businesses amid the current Covid-19 pandemic,
bearing in mind that financial penalties imposed should not be crushing or cause undue
hardship on organisations. Although a lower financial penalty has been imposed in this

case, the quantum of financial penalty should be treated as exceptional and should not be
taken as setting any precedent for future cases.

11.

Taking into account all relevant facts and circumstances, the Deputy Commissioner
hereby directs the Organisation to:

(a) Pay a financial penalty of $8,000 in 10 instalments by the due dates as set out
below, failing which, the full outstanding amount shall become due and payable
immediately and 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:

1st instalment of $800 on 1 January 2021;

ii.

2nd instalment of $800 on 1 February 2021;

iii.

3rd instalment of $800 on 1 March 2021;

iv.

4th instalment of $800 on 1 April 2021;

5th instalment of $800 on 1 May 2021;

vi.

6th instalment of $800 on 1 June 2021;

vii.

7th instalment of $800 on 1 July 2021;

viii.

8th instalment of $800 on 1 August 2021;

ix.

9th instalment of $800 on 1 September 2021; and

10th instalment of $800 on 1 October 2021

12.

In view of the remedial actions taken by the Organisation, the Deputy Commissioner will
not be issuing any other directions.

",Financial Penalty,4d881a08a671b9937b7e44b95f8f13e43eadd144
76,76,1,952,"Directions were imposed on Everlast Projects, Everlast Industries (S) and ELG Specialist for breaches of the PDPA. First, the organisations failed to put in place reasonable measures to protect their employees’ personal data. Second, they did not have written policies and practices necessary to ensure its compliance with the PDPA.","[""Accountability"", ""Protection"", ""Directions"", ""Construction"", ""No Policy"", ""Ransomware""]",2020-12-18,https://www.pdpc.gov.sg/-/media/Files/PDPC/PDF-Files/Commissions-Decisions/Decision---Everlast-Projects-and-Others---301020.pdf,"Accountability, Protection","Breach of the Accountability and Protection Obligations by Everlast Projects, Everlast Industries (S) and ELG Specialist",https://www.pdpc.gov.sg/all-commissions-decisions/2020/12/breach-of-the-accountability-and-protection-obligations-by-everlast-projects,2020-12-18,"PERSONAL DATA PROTECTION COMMISSION

[2020] SGPDPC 20

Case No. DP-1908-B4369

In the matter of an investigation under section 50(1)
of the Personal Data Protection Act 2012
And
(1) Everlast Projects Pte Ltd
(2) Everlast Industries (S) Pte Ltd
(3) ELG Specialist Pte Ltd
… Organisations

DECISION

Everlast Projects Pte Ltd & Others

[2020] SGPDPC 20

Everlast Projects Pte Ltd & Others
[2020] SGPDPC 20

Yeong Zee Kin, Deputy Commissioner — Case No. DP-1908-B4369
30 October 2020

Introduction
1

On 29 September 2019, Everlast Projects Pte Ltd (“EPPL”) notified the

Personal Data Protection Commission (“Commission”) that its server (“Server”) had
been hacked and all the files within it were encrypted by ransomware sometime in
August 2019 (the “Incident”).
Facts of the Case
2

EPPL, Everlast Industries (S) Pte Ltd (“EIPL”) and ELG Specialist Pte Ltd

(“ESPL”) (collectively, the “Organisations”) specialise in the supply and installation of
architectural metal works, glass and aluminium products. The Organisations are
owned by the same shareholder, managed by the same directors, and operate from
common premises. Two of the Organisations also have a common name, “Everlast”.
The Organisations operated like a group of companies and centralised their payroll
processing, such that the human resources (“HR”) department of EPPL was in charge
of processing payrolls of not only its own employees, but also the employees of EIPL
and ESPL. The Organisations’ employees’ personal data were stored in the Server,
which was owned and maintained by EPPL.
3

On 10 August 2019, EPPL discovered the Incident. EPPL had both an onsite

physical backup and a secondary cloud backup of the contents of the Server. The
physical backup was affected by the ransomware and rendered unusable. A total of
384 individuals were affected by the Incident (the “Affected Employees”):
2

Everlast Projects Pte Ltd & Others

[2020] SGPDPC 20

Name of Organisation

Number of employees affected

EPPL

141

EIPL

239

ESPL

Total number of individuals

384

The types of personal data of the Affected Employees that were at risk of

unauthorised access included the following (collectively, the “Personal Data Sets”):
(a)

Name;

(b)

NRIC/FIN number;

(c)

Date of birth;

(d)

Bank account details; and

(e)

Information relating to salary.

The cause of the ransomware infection was not identified. EPPL’s

investigations could not determine how the ransomware gained entry to the Server.
EPPL was also unable to confirm whether any of the Personal Data Sets had been
exfiltrated as a result of the Incident. Upon discovery of the Incident, EPPL took prompt
remedial action by ceasing to use the Server immediately.
6

Findings and Basis for Determination

The two issues to be determined in this case are as follows:
(a)

Whether the Organisations had each complied with their obligations under
section 12 of the Personal Data Protection Act 2012 (the “PDPA”); and

(b)

Whether the Organisations had each complied with their obligations under
section 24 of the PDPA.
3

Everlast Projects Pte Ltd & Others

[2020] SGPDPC 20

Whether EPPL, EIPL and ESPL had each complied with their obligations under section
12 of the PDPA
8

Section 12 of the PDPA requires organisations to, inter alia, develop and

implement policies and practices that are necessary for the organisation to meet its
obligations under the PDPA, and to communicate information about such policies and
practices to its staff (the “Accountability Obligation”).
9

In this regard, it is important to reiterate that an organisation’s Data Protection

Policies should be documented in a written policy, as per Re Furnituremart.sg [2017]
SGPDPC 7 at [14]:
“[t]he lack of a written policy is a big drawback to the protection of personal data. Without having
a policy in writing, employees and staff would not have a reference for the Organisation’s policies
and practices which they are to follow in order to protect personal data. Such policies and
practices would be ineffective if passed on by word of mouth, and indeed, the Organisation may
run the risk of the policies and practices being passed on incorrectly. Having a written policy is
conducive to the conduct of internal training, which is a necessary component of an internal data
protection programme.”

As mentioned at [2], EPPL, EIPL and ESPL operated as a group of companies

in the sharing of payroll processing services, which are centralised within the HR
department of EPPL. The Commission recognises the commercial benefits which arise
from centralising common corporate functions within a group of companies. In such
situations, one entity (the “Servicing Organisation”) provides corporate services to
other entities in the same corporate group (each a “Contracting Organisation”). If
the shared common corporate services involve the processing of personal data, the
Servicing Organisation would be acting as a data intermediary for each Contracting
Organisation.1
11

The common corporate service shared by the Organisations in the present case

was the payroll processing function. EIPL and ESPL were therefore permitted to
collect, without consent, their respective Affected Employees’ Personal Data Sets and

See the Commission’s Advisory Guidelines on Key Concepts in the PDPA (revised 2 June 2020) at [6.28].

Everlast Projects Pte Ltd & Others

[2020] SGPDPC 20

disclose the same to EPPL for the purposes of managing the employment
relationship.2 In these circumstances, EPPL was:
(a)

A data controller with respect to its own Affected Employees’ Personal

Data Sets; and
(b)

EIPL and ESPL’s data intermediary with respect to their respective

Affected Employees’ Personal Data Sets that EPPL was processing on their
behalf.
12

The Organisations admitted that they did not have any written data protection

policies and relied only on verbal instructions to employees. Although the
Organisations are in the construction industry and, in this case, do not typically collect
personal data from customers, the Accountability Obligation required the
Organisations to put in place data protection policies in relation to the protection of
personal data of their respective employees.
13

In this regard, organisations operating as a group of companies may comply

with the Accountability Obligation through binding group-level written policies or intragroup agreements that set out a common and binding standard for the protection of
personal data across all organisations in the same corporate group. These binding
group-level written policies or intra-group agreements are akin to binding corporate
rules (“BCRs”) imposed by an organisation on its overseas recipient of the personal
data (in compliance with the Transfer Limitation Obligation under Section 26(1) of the
PDPA), which oblige the overseas recipient to provide a standard of protection to the
transferred personal data that is at least comparable to that under the PDPA. 3 Where
the corporate group is a multinational corporation (“MNC”) and the Contracting
Organisation transfers personal data to an overseas Servicing Organisation, the
binding group-level written policies, intra-group agreements or BCRs which meet the

See Second Schedule of the PDPA, para 1(o) and Fourth Schedule of the PDPA, para 1(s).
The Transfer Limitation Obligation under Section 26 of the PDPA requires an organisation that transfers
personal data to a country or territory outside of Singapore to take appropriate steps to ensure that the
recipient of personal data is bound by legally enforceable obligations to provide to the transferred personal
data a standard of protection that is at least comparable to that under the PDPA.
3

Everlast Projects Pte Ltd & Others

[2020] SGPDPC 20

requirements of the Protection Obligation under section 24 of the PDPA4 would also
meet the requirements of section 26(1) of the PDPA in relation to the Protection
Obligation.5
14

In the present case, the Organisations did not have any such binding group-

level written policies, intra-group agreements or BCRs. In the circumstances, I find
each of EPPL, EIPL and ESPL in breach of the Accountability Obligation.
Whether EPPL, EIPL and ESPL had contravened section 24 of the PDPA
15

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 or
similar risks (the “Protection Obligation”). The obligation to make reasonable security
arrangements does not attach unless the organisation is in possession or control of
personal data.
16

As mentioned at [10], EPPL was (i) a data controller with respect to its own

Affected Employees’ Personal Data Sets; and (ii) EIPL and ESPL’s data intermediary
with respect to their Affected Employees’ Personal Data Sets that EPPL was
processing on their behalf. In this regard, EPPL, EIPL and ESPL had possession
and/or control of the Affected Employees’ Personal Data Sets at the material time.
(a)

EPPL was in possession and control of the Affected Employees’ Personal Data
Sets. This was because the Organisations’ payroll processing functions were
centralised within the HR department of EPPL.

(b)

While EIPL and ESPL did not have possession of their respective Affected
Employees’ Personal Data Sets because they were centrally hosted on EPPL’s
Server, I find that EIPL and ESPL remained in control of their respective Affected
Employees’ Personal Data Sets as data controllers. This is because the

4
5

The Protection Obligation is explained at paragraph 14.
See, for illustration, Re Cigna Europe Insurance Company S.A.-N.V. [2019] SGPDPC 18 at [13].

Everlast Projects Pte Ltd & Others

[2020] SGPDPC 20

processing of EIPL’s and ESPL’s Affected Employees Personal Data Sets by
EPPL was for EIPL’s and ESPL’s respective business purposes.6
17

Each of the Organisations were therefore obliged to put in place reasonable

security arrangements to protect the Affected Employees Personal Data Sets,
including preventing the risk of unauthorised modification. In the present case, the
Commission’s investigations into the Incident revealed that the ransomware had
encrypted all the files in the Server and its physical backup, including the Affected
Employees’ Personal Data Sets. The unauthorised modification of the Affected
Employees’ Personal Data Sets by the ransomware made it unreadable and unusable.
18

It is well established that a data controller should have in place a written contract

with its data intermediary that clearly specifies the data intermediaries’ obligation to
protect personal data. 7 That said, the relationship between the Organisations is a
relevant factor in determining the reasonable security measures expected of them to
comply with the Protection Obligation. In this regard, for a group of companies, the
written contract requirement between a Servicing Organisation and the Contracting
Organisation may be met by binding group-level written policies, intra-group
agreements or BCRs as discussed at [13] above.
19

In addition to a written agreement specifying data protection requirements, a

Contracting Organisation should also implement operational processes so as to be
able to exercise some form of supervision or control over the activities of the Servicing
Organisation when it processes personal data on the Contracting Organisation’s
behalf.8 Where the Servicing Organisation has specialised knowledge, skills and/or
tools for processing personal data, having a robust audit framework could be an
appropriate form of oversight. This may be particularly suited for MNCs which typically

See Re The Cellar Door Pte Ltd and another [2016] SGPDPC 22 at [17] – [18]; Re AIG Asia Pacific Insurance Pte
Ltd [2018] SGPDPC 8 at [18].
7

See the Commission’s Guide on Data Protection Clauses for Agreements relating to the Processing of Personal
Data (20 July 2016) at [4]; Re Singapore Telecommunications Limited [2017] PDPC 4 at [14]
8
The Commission’s Advisory Guidelines on Key Concepts in the PDPA (revised 2 June 2020) at [17.5] provides
that “[e]nsuring that IT service providers are able to provide the requisite standard of IT security” is an
example of a technical measure an organisation may use to protect personal data.

Everlast Projects Pte Ltd & Others

[2020] SGPDPC 20

conduct periodic internal and/or external audits and assessments to monitor
compliance by each organisation within the corporate group.9 Conversely, small and
medium-sized enterprises that only operate in Singapore are less likely to conduct
such compliance audits on each organisation in the corporate group in the areas of
cybersecurity and/or data protection. In such situations, appropriate oversight could
involve more simple processes. For example, requiring the Servicing Organisation to
explain to the Contracting Organisation the measures which would be taken to secure
personal data, with appropriate documentation to evidence this process (e.g. written
acknowledgement given by the Contracting Organisation to the Servicing
Organisation), and provide regular reports showing that it has put these processes in
place.
20

In the present case, both EIPL and ESPL failed to put in place reasonable

security arrangements to ensure that EPPL (who was their data intermediary for the
purposes of payroll processing) would protect their respective Affected Employees’
Personal Data Sets. There was no written contract, intra-group agreement or grouplevel written policies/BCRs setting out data protection requirements that EPPL was
obliged to comply with when processing EIPL’s and ESPL’s respective Affected
Employees’ Personal Data Sets. Notwithstanding that the Organisations conducted
their business operations from the same premises, both EIPL and ESPL also did not
implement any operational processes to supervise or exercise some form control over
EPPL to ensure EPPL protected their Affected Employees’ Personal Data Sets. In the
circumstances, I find each of EIPL and ESPL in breach of the Protection Obligation.
21

EPPL was also obliged to comply with the Protection Obligation. As mentioned

in [10], it was: (i) a data controller with respect to its own Affected Employees’ Personal
Data Sets; and (ii) EIPL and ESPL’s data intermediary with respect to their Affected
Employees’ Personal Data Sets. The Commission’s Investigations revealed that EPPL
did not put in place reasonable security arrangements to protect the Personal Data
Sets as explained below:

As an example, see Re Cigna Europe Insurance Company S.A.-N.V. [2019] SGPDPC 18 at [7(c)].

Everlast Projects Pte Ltd & Others

(a)

[2020] SGPDPC 20

EPPL did not install a firewall for the Server. Without a firewall, the Server and
corporate network was vulnerable to web-based security threats;10

(b)

EPPL did not conduct periodic security reviews of its IT systems, including
vulnerability scans of the Server, to assess the overall security of its IT
infrastructure. The requirement for organisations to conduct periodic security
reviews of its IT systems has been emphasized in previous decisions. 11
Conducting regular information and communication technology (“ICT”) security
audits, scans and tests to detect vulnerabilities help organisations to ensure
that ICT security controls developed and configured for the protection of
personal data are properly implemented. 12 The comprehensiveness of such
security reviews should be scoped based on the organisation’s assessment of
its data protection needs, and be conducted to a reasonable standard. The
scope and level of the review would depend on the type of personal data to be
protected. In this case, as the Personal Data Sets included personal data of a
financial nature (e.g. information relating to bank accounts and salaries), a
higher standard of periodic security review was required of EPPL in order to
comply with the Protection Obligation. If EPPL had conducted a security review
of its IT system to a reasonable standard, it would have discovered the absence
of a firewall for the Server; and

(c)

EPPL was unable to provide any written IT security policies (e.g. password
policy, policies for patching and updating of the company server, etc.). 13 In this
regard, EPPL conceded that they did not know what was required in order to
protect personal data in electronic form.

The Commission’s Guide to Securing Personal Data in Electronic Medium (20 January 2017) at [9.1] states as
follows: “It is important for an organisation to ensure that its corporate computer networks are secure.
Vulnerabilities in the network may allow cyber intrusion, which may lead to theft or unauthorised use of
electronic personal data. Defences that may be used to improve the security of networks include: […]
Firewalls”.
11
See, for example, Re WTS Automotive Services Pte. Ltd. [2018] SGPDPC 26 at [18], Re Bud Cosmetics [2019]
SGPDPC 1 at [24] and Re Chizzle Pte. Ltd. [2019] SGPDPC 44 at [6] to [8].
12
Commission’s Guide to Securing Personal Data in Electronic Medium (revised 20 January 2017) at [6.1].
13
The Commission’s Advisory Guidelines on Key Concepts in the PDPA (revised 2 June 2020) at [17.5] provides
that “[s]ecurity arrangements may take various forms such as administrative measures, physical measures,
technical measures or a combination of these”. Having robust policies and procedures is an example of an
administrative measure an organisation may implement by way of security arrangements.

Everlast Projects Pte Ltd & Others

[2020] SGPDPC 20

For the reasons above, I also find EPPL in breach of the Protection Obligation.

Directions
23

In determining the directions, if any, to be imposed on EPPL, EIPL and ESPL

under section 29 of the PDPA, I took into account the following factors:
(a)

The Organisations had voluntarily notified the Commission of the Incident;

(b)

The Commission did not receive any complaints of the Personal Data Sets being
disclosed online or otherwise misused;

(c)

There was no evidence of exfiltration of the Personal Data Sets; and

(d)

An imposition of a financial penalty would impose a crippling burden and cause
undue financial hardship due to the financial position of the Organisations.

Having considered all the relevant factors of this case, I direct EPPL, EIPL and

ESPL to:
(a)

Develop and implement intra-group agreements or binding corporate

rules that set out a common and binding standard for the processing of personal
data when centralising common corporate activities within the group, within 90
days from the date of this direction;
(b)

Review and ensure that the internal policies within each of EPPL, EIPL

and ESPL are in line with the standards set forth in the intra-group agreements
or binding corporate rules, within 90 days from the date of this direction; and
(c)

Inform the Commission of the completion of the directions set out at

[23(a)] and [23(b)] within one week.

YEONG ZEE KIN
DEPUTY COMMISSIONER
FOR PERSONAL DATA PROTECTION
10

",Directions,6bf33286d1c3d26557836242297e0273d9b08921
77,77,1,952,"A financial penalty of $4,000 was imposed on Novelship for failing to put in place reasonable security arrangements to protect the personal data collected from its sellers from unauthorised access on its website.","[""Protection"", ""Financial Penalty"", ""Wholesale and Retail Trade"", ""Public access"", ""URL manipulation"", ""No Security Arrangements""]",2020-11-24,https://www.pdpc.gov.sg/-/media/Files/PDPC/PDF-Files/Commissions-Decisions/Decision---Novelship-Pte-Ltd---22072020.pdf,Protection,Breach of the Protection Obligation by Novelship,https://www.pdpc.gov.sg/all-commissions-decisions/2020/11/breach-of-the-protection-obligation-by-novelship,2020-11-24,"PERSONAL DATA PROTECTION COMMISSION
Case No. DP-1905-B3820
In the matter of an investigation under section 50(1) of the
Personal Data Protection Act 2012
And
Novelship Pte. Ltd.
SUMMARY OF THE DECISION

Novelship Pte. Ltd. (the “Organisation”) operates an e-commerce website for
individuals to sell or buy luxury brands of streetwear (the “Website”). To create
a buyer or seller account on the Website, individuals would have to provide their
personal data to the Organisation. The Organisation does not, in usual course,
reveal the personal data it had collected to any buyer or seller transacting on the
Website. Instead, the Organisation, together with an external payment
processor, facilitates transaction payments on behalf of the parties.

On 1 May 2019, the Personal Data Protection Commission (the “Commission”)
received information that a registered seller (“User”) was able to gain
unauthorised access to the personal data of other sellers by employing software
tools and manipulating the public URLs of active listings (“the “Incident”).

The User had accessed the personal data of six unique sellers who had active
listings at the time of the Incident. The personal data concerned included: (i) first
and last names; (ii) email addresses; (iii) shipping addresses; (iv) hashed
account passwords; and (v) the name of bank and bank account numbers
(“Personal Data Sets”). No buyer data was accessed in the Incident.

Investigations revealed that the Organisation had not conducted adequate
security testing before the launch of the Website. The testing it had conducted
was limited to design and functionality issues, such as verifying the password
hashing and password requirement functions. Critically, the Organisation
should have—but had not—conducted vulnerability scanning. Vulnerability
scanning that is reasonably and competently conducted should include scanning
for OWASP Top Ten, i.e. the top 10 security vulnerabilities listed by the Open
Web Application Security Project (“OWASP”). The vulnerability of URLs to
manipulation is within the OWASP Top 10, and would have been detected if the
Organisation had conducted adequate vulnerability testing.

The Commission understands that not every organisation is equipped with
adequate knowledge of cyber security risks or the ability to conduct security
testing. However, the obligation of organisations to protect the personal data they
collect and process online cannot depend on their subjective familiarity with the
security risks or ability to prevent them. Organisations are expected to engage
qualified competent parties, where reasonably needed, to assist them to
discharge their obligation to protect personal data. When doing so, organisations
can refer on the technical advice and expertise of their service provider, but
remain ultimately responsible for articulating the business risks they wish to avoid
and business outcomes that they seek to achieve.

Similarly, the Commission recognises that organisations may face financial,
manpower and technical limitations. These limitations are relevant in establishing
the reasonableness of decisions they have taken, but cannot allow an
organisation to justify providing a level of protection that is below what is
reasonable for the type of personal data it collects and processes.

Accordingly, the Deputy Commissioner for Personal Data Protection finds the
Organisation in breach of the Protection Obligation under section 24 of the
Personal Data Protection Act 2012.

Having considered the representations made by the Organisation and the
material factors, in particular:
(a)

the sellers’ personal data would have been at risk of unauthorised access
for a period of eight months (from the time the sellers were first allowed to
sell on the Website, to the date remedial actions were taken);

(b)

there was actual unauthorised access of the Personal Data Sets of six
individuals by the User;

(c)

the remedial measures taken by the Organisation upon being made aware
of the Incident; which included fixing the vulnerability to ensure that the
sellers’ personal data would no longer be accessible to unauthorised
persons, redacting all user information relating to bank information, and the
Organisation committing to developing a new website; and

(d)

the adverse impact the COVID-19 pandemic had on the Organisation’s
business;

the Deputy Commissioner for Personal Data Protection directs that the
Organisation pays a financial penalty of S$4,000 for the contravention. The
Organisation must make payment of the financial penalty 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 the financial penalty until it is paid in full. No other
directions are required as the Organisation had implemented the necessary
remedial measures.

",Financial Penalty,e78daf1170808149ba7ab6af446c1836acb0e555
78,78,1,952,"A financial penalty of $5,000 was imposed on Worksmartly for breaches of the PDPA. First, the Organisation failed to put in place reasonable security arrangements to protect the personal data of its client’s employees. Second, it was also found to be retaining personal data which was no longer necessary for legal or business purposes.","[""Protection"", ""Retention Limitation"", ""Financial Penalty"", ""Admin and Support Services"", ""Database"", ""Public access"", ""Retention""]",2020-11-24,https://www.pdpc.gov.sg/-/media/Files/PDPC/PDF-Files/Commissions-Decisions/Decision----Worksmartly-Pte-Ltd---17092020.pdf,"Protection, Retention Limitation",Breach of the Protection and Retention Limitation Obligations by Worksmartly,https://www.pdpc.gov.sg/all-commissions-decisions/2020/11/breach-of-the-protection-and-retention-limitation-obligations-by-worksmartly,2020-11-24,"PERSONAL DATA PROTECTION COMMISSION
Case No. DP-2004-B6162

In the matter of an investigation under section 50(1) of the
Personal Data Protection Act 2012
And
Worksmartly Pte. Ltd.

SUMMARY OF THE DECISION

On 2 April 2020, Roche Singapore Pte Ltd (“Roche”) informed the Personal Data
Protection Commission (the “Commission”) of a data security incident involving its
former vendor, Worksmartly Pte. Ltd. (the “Organisation”). Roche had detected an
unauthorised disclosure of their employees’ data on GitHub repository (“GitHub”) on 3
March 2020 (the “Incident”).

The Organisation subsequently requested for this matter to be handled under the
Commission’s expedited decision procedure. In this regard, the Organisation voluntarily
provided and unequivocally admitted to the facts set out in this decision. It also admitted
that it was in breach of sections 24 and 25 of the Personal Data Protection Act (the
“PDPA”).

Background
3.

The Organisation was engaged by Roche in 2017 to provide finance and payroll
processing services. In order for the Organisation to provide the said services, Roche
handed over its employees’ personal data to the Organisation. The contract between the
parties was subsequently terminated, and the Organisation’s last day of service was 31
December 2018.

The Incident
4.

On or around 28 February 2020, one of the Organisation’s employees uploaded a file on
the Organisation’s GitHub account (the “File”). When doing so, the employee changed
the setting of the GitHub account from “private” to “public” under the mistaken belief
that the File would only be accessible to other members of the Organisation. In fact, the
change in setting had resulted in the File being accessible to the public.

The File contained the personal data of 308 individuals, which comprised Roche’s
current and former employees (the “Employees”), and their dependents (the
“Dependents”). The personal data included:
a.

For the Employees: name, NRIC/FIN/Passport number, address, date of birth,
race, citizenship, employee ID, Roche email address, role title, employment
commencement date, salary, bank account name and numbers and name of bank;
and

For the Dependents: name, NRIC/FIN/Passport number, date of birth and contact
number.

The File was used for data migration during the initial service engagement in 2017. The
File was supposed to have been deleted—along with other files containing Roche’s
employees’ data—before the Organisation’s last day of service, i.e. 31 December 2018.
However, because the File was stored in a different folder from the other files, the
Organisation had inadvertently omitted to delete the File. This led to the File being
exposed to the public when the Organisation’s employee set the GitHub folder’s setting
to “public” as stated at [4] above.

The File was exposed to the public for a period of five days from 28 February 2020 to 3
March 2020. Based on GitHub’s logs, the repository containing the File was accessed 23
times and downloaded 11 times during this time.

The Contraventions
8.

The Organisation admitted that it lacked checks to manage the correct security settings
of its GitHub account and had relied solely on employees to do the right thing. The
Organisation also admitted that it had not conducted the necessary housekeeping and
maintenance of files, which resulted in retaining the File when it was no longer required
for business or legal purposes.

In the circumstances, the Deputy Commissioner for Personal Data Protection finds the
Organisation in breach of the Protection Obligation under section 24 and Retention
Obligation under section 25 of the PDPA.

10.

Upon realising the Incident, the Organisation took the following remedial action:
a.

Immediately set the GitHub access to “private” and deleted the File;

Reset the passwords for all the databases and servers;

Conducted housekeeping to ensure removal of obsolete files from GitHub;

Directed its GitHub account administrator to always set the repositories to
“private” and introduced a disciplinary framework for the mishandling of its
GitHub accounts.

The Decision
11.

The Deputy Commissioner for Personal Data Protection notes that the Organisation had
admitted to a breach of Protection and Retention Obligations under the PDPA, and had
cooperated with the Commission’s investigation and taken prompt remedial action.

12.

On account of the above, the Deputy Commissioner for Personal Data Protection directs
the Organisation to pay a financial penalty of $5,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).

13.

In view of the remedial actions taken by the Organisation, the Commission will not be
issuing any other directions.

",Financial Penalty,583ab7758251c5c2e5fe07f3e5f542c582089f9d
79,79,1,952,"A financial penalty of $20,000 was imposed on Times Software, a data intermediary, for: (i) failing to make reasonable security arrangements to prevent the unauthorised disclosure of personal data belonging to the employees of its clients; and (ii) retaining personal data which was no longer necessary for legal or business purposes. Separately, Dentons and TMF were each issued a warning for failing to put in place reasonable security arrangements with Times Software to prevent unauthorised disclosure of the personal data belonging to their employees.","[""Protection"", ""Retention Limitation"", ""Financial Penalty"", ""Legal"", ""Data Intermediary"", ""Functionality"", ""Software""]",2020-11-24,https://www.pdpc.gov.sg/-/media/Files/PDPC/PDF-Files/Commissions-Decisions/Decision---Times-and-Others---18062020.pdf,"Protection, Retention Limitation","Breach of the Protection and Retention Limitation Obligations by Times Software, Breach of the Protection Obligation by Dentons and TMF",https://www.pdpc.gov.sg/all-commissions-decisions/2020/11/breach-of-the-protection-and-retention-limitation-obligations-by-times-software-breach-of-the-protection-obligation-by-dentons-and-tmf,2020-11-24,"PERSONAL DATA PROTECTION COMMISSION

[2020] SGPDPC 18
Case Nos.: DP-1802-B1719, DP-1802-B1744,
DP-1803-B1834, DP-1804-B1942, DP-1804-B1943

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

And

(1) Times Software Pte Ltd
(2) Dentons Rodyk & Davidson
LLP
(3) Liberty Specialty Markets
Singapore Pte Limited
(4) Red Hat Asia Pacific Pte Ltd
(5) TMF Singapore H Pte Ltd

… Organisations

DECISION

Times Software Pte Ltd & Ors
[2020] SGPDPC 18
Tan Kiat How, Commissioner — Case Nos. DP-1802-B1719, DP-1802-B1744, DP1803-B1834, DP-1804-B1942, DP-1804-B1943
18 June 2020
Introduction
1

Times Software Pte Ltd (“Times”) is an information technology services vendor

that provides various services to its clients. Between January and February 2018,
three organisations which directly or indirectly used Times’ services became aware
that the personal data of some their current and former employees (the “Employee
Data”) had been exposed online from Times’ servers and could be found using the
Google search engine (the “Incident”). These three organisations were Dentons
Rodyk & Davidson LLP (“Dentons”), Red Hat Asia Pacific Pte Ltd (“Red Hat”) and
Liberty Specialty Markets Singapore Pte Limited (“LIU”). Each of these organisations
submitted a data breach notification to the Personal Data Protection Commission (the
“Commission”) after the Incident.
The Facts
The Relationship between the Parties and how Times had obtained the Employee
Data
2

Dentons had, since 2001, engaged Times to use a payroll software application

developed by Times (the “Payroll Software”). The Payroll Software was hosted
internally on Dentons’ servers. In or around November 2015, Dentons commissioned
the development of a new functionality of the Payroll Software which would enable

Times Software Pte Ltd & Ors

2020 SGPDPC [18]

Dentons to create customised employee reports. Dentons provided their Employee
Data to Times to test this functionality.
3

In December 2015 and February 2016, Red Hat and LIU respectively engaged

TMF Singapore H Pte Ltd (“TMF”), a professional services company, for certain HR
and payroll services. For this purpose, Red Hat and LIU provided TMF with their
Employee Data.
4

In turn, TMF had, since 2008, engaged Times to use the Payroll Software to

provide services to its clients, including Red Hat and LIU. The Payroll Software was
hosted on TMF’s servers. Sometime between December 2015 and February 2016,
TMF provided Times with Red Hat and LIU’s Employee Data. The reason for doing so
was disputed by TMF and Times:
(a)

According to Times, TMF had provided the Employee Data for a one-

time exercise which involved data migration and the development of a new
functionality within the Payroll Software;
(b)

In contrast, TMF asserted that the data migration and development of a

new functionality within the Payroll Software were two separate and unconnected
requests to Times. In this regard, TMF claimed that it had provided the Employee
Data of Red Hat’s and LIU’s to Times only for the purposes of data migration,
and was not aware of—and did not consent to—Times’ use of the Employee Data
to develop the functionality.
5

There was insufficient contemporaneous evidence to support either party’s

version of events. In particular, TMF and Times did not have a written agreement on
the handing over of the Employee Data which could have provided more context. In
any event, there is no need to make a finding on which version of events is to be
believed. As explained further at [36] below, the findings regarding TMF’s breach of
its Protection Obligation under Section 24 of the Personal Data Protection Act 2012
(“PDPA”) are not dependent on whether TMF had consented to Times’ use of Red
Hat’s and LIU’s Employee Data to develop the functionality within the Payroll Software.
2

Times Software Pte Ltd & Ors

2020 SGPDPC [18]

The Disclosure of the Employee Data
6

The Employee Data handed over to Times by Dentons and TMF was stored in

Times’ File Server System (“FSS”). Between 21 December 2017 and 23 December
2017, Times suffered a hard disk failure in its FSS. To remediate this, Times restored
a backup of the data in the FSS on or around 23 December 2017 and reset the FSS
operating system settings to their default settings, which included disabling the
password protection feature. As the FSS was accessible over the Internet, the
Employee Data that was stored in the FSS was exposed to web crawlers and indexed
by the Google search engine and stored in Google’s cache.
7

In total, 616 employees had their Employee Data exposed over the Internet from

23 December 2017 to around mid-February 2018. This number comprised 400
employees from Dentons, 162 employees from Red Hat, and 54 employees from LIU.
The types of Employee Data which was exposed during the Incident included:
(a)

For Dentons: name, NRIC or other identification number, residential

address, contact number, work designation, duration of employment and base
salary;
(b)

For Red Hat and LIU: name, NRIC or other identification number, date

of birth, marital status, nationality, race, base salary, bank account information,
income tax account number, addresses and mobile number.
8

Upon discovery of the Incident, the organisations took the following remedial

actions:
(a)

Times:
(i)

Took action to take down all links to the Employee Data by

contacting Google and other search engines (i.e., Bing and Archive.org);
(ii)

Took all server hosting development files offline so that they were

no longer available on the Internet and could only be accessed internally
via Local Area Network with proper authentication;
3

Times Software Pte Ltd & Ors

(iii)

2020 SGPDPC [18]

Developed additional policies and SOP on data handling for its

employees, which included the following requirements:
(A)

Heads of departments are now required to conduct a

weekly audit to ensure sensitive files are destroyed upon
completion of work;
(B)

Cross-department audits are to be done on a monthly

basis, as well as upon completion of work;
(C)

Random audits are to be done by the IT manager on a bi-

monthly basis; and
(D)

Servers published online will no longer accept unencrypted

files.
(b)

LIU:
(i)

Imposed more stringent contractual provisions on TMF with

regard to the services it is providing including dealing with data breaches
or the protection of personal data;
(ii)

Worked with Times to ensure that all relevant data, including the

Employee Data, had been removed from Times’ environments;
(iii)

The Liberty Mutual Global IT Team undertook a comprehensive

security review of TMF’s services; and
(iv)
(c)

Notified all its current employees of the Incident.

Red Hat:
(i)

Being the first party to discover the breach, notified Google to take

down the Employee Data;
(ii)

Notified all current employees and former employees of the

Incident and offered free credit monitoring service to the affected
employees; and
4

Times Software Pte Ltd & Ors

(iii)

2020 SGPDPC [18]

Obtained assurance from TMF and Times that Times had

disabled the internal folder from public view, and that Times would perform
audits to ensure all servers published on the internet that are meant for
internal use were password-protected.
(d)

Dentons:
(i)

Notified its employees of the Incident; and

(ii)

Obtained assurance from Times that all servers connected to the

Internet were password protected.
(e)

TMF:
(i)

Ceased to allow Times to retain any of its clients’ information for

development purposes, and set up a UAT environment for Times for future
development of additional functionalities.
Findings and Basis for Determination
Breach by Times of Sections 24 and 25 of the PDPA
9

Times was a data intermediary1 of Dentons as it processed personal data on

behalf of, and for the purposes of Dentons. As explained further at [27] below, Times
was also a data intermediary of TMF as it processed personal data on behalf of, and
for the purposes of TMF, the relevant data here being Red Hat’s and LIU’s Employee
Data.
10

A data intermediary is subject to both the Protection Obligation and the Retention

Limitation Obligation under Section 242 and Section 253 of the PDPA. The
Commission’s investigations showed that Times had breached both these obligations.
Section 2 of the PDPA defines “data intermediary”.
Section 24 of the PDPA requires organisations to protect personal data in their possession or under its control
by making reasonable security arrangements to prevent unauthorised access, collection, use, disclosure, copying,
modification, disposal or similar risks.
3
Section 25 of the PDPA requires an organisation to cease to retain its documents containing personal data, or
remove the means by which the personal data can be associated with particular individuals, as soon as it is
1
2

Times Software Pte Ltd & Ors

2020 SGPDPC [18]

In relation to the Protection Obligation, Times had breached it in two ways. First,

the processes in remediating the hard disk failure in its FSS fell short of the standard
required under Section 24 of the PDPA. Times’ Standard Operating Protocol (“SOP”)
required the employee who carried out the server restoration to enable the
authentication function, i.e. password-protect function, so that only a user with proper
credentials would be granted access to the data in the FSS. The employee’s
supervisor was also required to check that the authentication function was enabled.
However, the relevant employee had failed to enable the authentication function after
the server restoration. This was not discovered by the employee’s supervisor as the
supervisor did not take any measures to confirm that the authentication function was
enabled.
12

It can be seen that even though Times had SOPs in place, the fact Times had

not detected the employee’s error in not enabling the authentication function shows
that the security arrangement was not sufficiently reasonable. As set out in Re
Marshall Cavendish Education Pte Ltd [2019] SGPDPC 34 at [21], “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”. Given the amount and type of personal data that Times was
processing, Times should have ensured that their SOP included specific procedures
that were designed to reasonably detect non-compliance and to discourage deliberate,
reckless or careless failures to adhere to the SOP by its employees.
13

Second, Times’ other internal policies also fell short of reasonable protection

expected for an organisation that handles the amount and type of personal data that
Times handled:
(a)

Times had poor password management policies in place. It was the

prevailing practice of Times’ employees to set the same password to the FSS
prior to and after a server restoration. While this may be permissible for certain

reasonable to assume that the purpose for which that personal data was collected is no longer being served by the
retention of the personal data, and retention is no longer necessary for legal or business purposes.

Times Software Pte Ltd & Ors

2020 SGPDPC [18]

more routine restorations in the course of operational maintenance,
organisations should set new passwords for server access control, especially
where there has been a restoration of the server after security incidents;
(b)

The Employee Data included bank account numbers and salaries. As

the disclosure of such data may have a direct and significant impact on the
individuals concerned, additional measures should have been adopted by Times
to protect such data, for example, by encrypting such data, when storing such
data in the FSS. This has been emphasised by the Commission in its Guide to
Security Personal Data in Electronic Medium (Revised 20 January 2017); and
(c)

Times should not have used live customer data for testing purposes. As

highlighted in the Commission’s Guide to Basic Data Anonymisation Techniques
(Published 25 January 2018), using live personal data for testing involved risks
as a development and/or test environment may be remotely accessed. Rather,
Times should have used either anonymised or synthetic data, so that testing of
the new functionality may be done without any risk to the personal data.4
14

As for Retention Limitation Obligation, Times admitted that the requested tool

was implemented in December 2015 and the Employee Data of Red Hat’s and LIU’s
Impacted Employee should have been deleted after that. In fact, Times’ SOP on
software development required employees to delete personal data once project signoff has been obtained. However, in breach of the SOP, the employee who assisted in
the development of the new functionality for the Payroll Software did not delete the
personal data provided by TMF. No checks were conducted to ensure that the SOP
was followed. Times had therefore contravened its Retention Limitation Obligation
under Section 25 of the PDPA.
15

In the course of settling this decision, Times made representations proposing to

take full responsibility for the Incident, and for a reduction in the quantum of financial

[13] of Guide to Basic Data Anonymisation Techniques.

Times Software Pte Ltd & Ors

2020 SGPDPC [18]

penalty that the Commissioner had intended to impose. Times raised the following
factors for consideration:
(a)

The Incident was the first data breach in Times’ 21 years of operations;

(b)

No damages were reported as a result of the Incident;

(c)

Times had improved their network security, conducted vulnerability

assessments, and improved their SOPs to reduce human errors; and
(d)
16

Their business had since been adversely affected by Covid-19.

Times’ proposal to take full responsibility for the Incident does not absolve the

other organisations that are also in breach. The PDPA imposes data protection
obligations on all organisations in relation to personal data in their possession or
control, and each organisation is individually responsible to comply with these
obligations.
17

The other factors raised at [15(a)]-[15(d)] have were considered in mitigation. In

particular, the exceptional challenges faced by businesses amid the current Covid-19
pandemic have been taken into account, bearing in mind that financial penalties
imposed should not be crushing or cause undue hardship on organisations.
18

All things considered, the financial penalty imposed on Times has been reduced

to $20,000 for the contravention of the Protection Obligation and Retention Limitation
Obligation of the PDPA. Although a lower financial penalty has been imposed in this
case, this is exceptional and should not be taken as setting any precedent for future
cases.
Breach by Dentons of Section 24 of the PDPA
19

Section 4(3) of the PDPA provides that an organisation has the same obligations

under the PDPA in respect of personal data processed on its behalf by a data
intermediary as if the personal data was processed by the organisation itself. This
8

Times Software Pte Ltd & Ors

2020 SGPDPC [18]

means that both the organisation and data intermediary each have an obligation to
make reasonable security arrangements to protect personal data that are in their
possession or under their control. The Commission has in previous decisions stated
that it is necessary for an organisation to put in place the appropriate contractual
provisions with its data intermediaries to set out the obligations and responsibilities of
the data intermediary to protect the organisation’s personal data, and the parties’
respective roles to protect the personal data.5
20

In this case, it is not disputed that there was no written contract between Dentons

and Times regarding the processing of the Employee Data by Times. Instead, Dentons
represented that it had relied on a letter issued by Times in July 2014 (the
“Statement”) to protect personal data as evidence in writing of the contract. The
salient terms of the Statement are reproduced below:
“As a Data Intermediary, Times Software Pte Ltd has always been
committed in protecting your personal data and will implement the
following standard operating procedures (SOP) to ensure that we are in
full compliance with the new ruling:
a) All employees of Times Software Pte Ltd (“staff”) must get
written consent from the customer before retrieving any
personal data (such as company database or payroll related
reports). The written consent must specify the identity and the
purpose of usage by the applicant.
b) Staff should not reveal, distribute or broadcast any personal
data that are deemed confidential by the client(s) even after
resignation.
c) Printed copies of clients’ confidential information or personal
data are not to be recycled or reused. They must be
immediately shredded upon completion of usage.
d) Staff are not allowed to keep or retain any customers’
personal data upon completion of its intended purpose stated
in the written consent.
e) Any electronic copies or duplications containing sensitive
information, personal data or material which are to be sent or
5

See for example Re Cellar Door and Ors [2016] SGPDPC 22 at [15]; Re Singapore Telecommunications
Limited [2017] PDPC 4 at [14]; Re Singapore Health Services Pte Ltd & Ors [2019] SGPDPC 3 at [59].

Times Software Pte Ltd & Ors

2020 SGPDPC [18]

received by clients via any electronic medium must be
encrypted with a password only known to the staff and the
client. The password must not be in the same communicated
e-mail or message. It should either be advised by phone
conversation, sent in via Short Messaging Service (SMS) or
in a separate mailer.”
[emphasis in original]
21

In the course of settling this decision, Dentons raised the following factors in

relation to the Statement for consideration:
(a)

The Statement is a contract between Times and Dentons that is legally

binding and fully enforceable. It contained three key commitments given by
Times to Dentons: (i) the commitment to protect Denton’s personal data and
Times’ full compliance with the PDPA; (ii) the commitment to not retain Denton’s
personal data upon completion of its intended purposes, and to shred such data
upon completion of use; and (iii) the commitment to encrypt all electronic copies
or duplications containing sensitive information or personal data which are to be
sent or received by Dentons;
(b)

The three commitments in the Statement mirror the obligations

contained in the template clauses in the Commission’s Guide on Data Protection
Clauses for Agreements in relating to Processing of Personal Data (Published
20 July 2016);
(c)

What is reasonable must be viewed in the context and the purposes for

which personal data was being provided. Having regard to the scope and context
of Denton’s engagement with Times, any other contractual obligations in addition
to the Statement would be superfluous, and place an onerous and unreasonable
burden on Dentons; and
(d)

Lastly, where an adequate level of protection had been achieved in the

circumstances (of the Statement), the Commission ought not to, with the benefit
of hindsight, impose onerous additional requirements on Dentons for not meeting
such enhanced requirements.
10

Times Software Pte Ltd & Ors

2020 SGPDPC [18]

Dentons’ representations that the Statement sufficed to discharge its Protection

Obligation are not accepted as Dentons had overstated the effect of the Statement.
While the Statement may meet the requirement of a contract evidenced in writing, it
suffered from a significant flaw. The Statement omitted to cover the expected standard
of protection for electronic storage of Employee Data. The commitments made by
Times in the Statement pertained only to the conduct of staff, the security of physical
copies of documents, and data protection (such as the need for encryption) during
electronic transmission. Notably, the Statement did not specify any requirements for
or include any commitments in relation to implementing security measures for the
electronic storage of Employee Data, which was most relevant and paramount given
that the Employee Data processed by Times was in electronic form and the Employee
Data handed over by Dentons to Times was stored electronically in the FSS as
mentioned at [6]. This was a serious omission of scope, which left the standard of
protection of a significant volume of electronic Employee Data unaccounted for.
23

The data protection commitments in the Statement were incomplete and could

not reasonably be relied on by Dentons as a security arrangement to protect the
Employee Data that was provided to Times.
24

Contrary to Dentons’ representations, the requirement for an organisation to put

in place contractual provisions to ensure its data intermediary will protect personal
data is neither onerous nor unreasonable. In this regard, the Commission’s Guide on
Data Protection Clauses for Agreements Relating to the Processing of Personal Data
(Published 20 July 2016) sets outs sample clauses that an organisation may adapt to
suit its needs. This is not an onerous process, and would not incur significant costs. In
this case, the Statement that was introduced into the ongoing contractual relationship
is sufficient written evidence of the data processing contract but it suffered from a
significant defect in scope as explained at [22] above.
25

As for Dentons’ representations that the Commission should not use the benefit

of hindsight to impose additional requirements on organisations, the requirement for
an organisation to ensure that its written contract with its data intermediary clearly
11

Times Software Pte Ltd & Ors

2020 SGPDPC [18]

specifies the data intermediary’s obligation to protect personal data is not new. As an
illustration, that requirement was referred to in an earlier version of the Commission’s
Advisory Guidelines on Key Concepts in the PDPA (issued in September 2013),
approximately two years before Dentons had provided its Employee Data to Times for
processing.
26

For the above reasons, the finding that Dentons had contravened the Protection

Obligation in failing to put in place the appropriate contractual provisions with Times
for the protection of their Employee Data was maintained. After taking into account the
relevant mitigating and aggravating factors listed at [44] below, it was decided that a
warning to Dentons for the breach would suffice in this case.
Breach by TMF of Section 24 of the PDPA
27

TMF was a data intermediary of Red Hat and LIU as it was engaged to provide

payroll services which involved the processing of Red Hat’s and LIU’s Employee Data.
As a data intermediary, TMF was subject to the Protection Obligation set out at Section
24 of the PDPA and was required to put in place reasonable security arrangements to
protect Red Hat’s and LIU’s Employee Data in its possession or under its control. What
the “reasonable security arrangements” entail will depend on the context.
28

Based on the Commission’s preliminary findings, it appeared that subsequent to

its engagement as Red Hat’s and LIU’s data intermediary, TMF had outsourced to
Times the processing of Red Hat’s and LIU’s Employee Data for payroll services. In
this scenario, Times was not only a data intermediary of TMF, but may also be referred
to as a “subsidiary data intermediary” of Red Hat and LIU.
29

To elaborate, the term “subsidiary data intermediary” may be used to describe

an organisation who is a sub-contractor to a data intermediary, and who is subcontracted to carry out data processing activities that are directly related and
necessary to what the said data intermediary is supposed to undertake for an
organisation (analogous to a data controller). As highlighted above, Times would be a
“subsidiary data intermediary” of Red Hat and LIU if TMF had outsourced to Times the
12

Times Software Pte Ltd & Ors

2020 SGPDPC [18]

processing of Red Hat’s and LIU’s Employee Data for payroll services, because TMF
was supposed to have performed these tasks in the contract TMF had with Red Hat
and LIU.
30

Subsequently, TMF clarified in its representations to the Commission’s

preliminary findings that it did not sub-contract to Times any processing of Red Hat’s
and LIU’s Employee Data for payroll services. Instead, it had provided Red Hat’s and
LIU’s Employee Data to Times for the purposes of a one-time data migration exercise.
As the data migration in this case was a different set of processing activity unrelated
to the payroll services that Red Hat and LIU had engaged TMF to provide, it would not
be appropriate to refer to Times as a “subsidiary data intermediary” of Red Hat and
LIU.
31

Although the term “subsidiary data intermediary” may be used to describe the

position the sub-contractor is in vis-à-vis the data controller (ie, it is a “subsidiary data
intermediary” of the data controller), the use of such a term is simply a convenient and
informal label to describe such sub-contractors in the context of data processing where
subcontracting is common. It has no legal implications; in particular, it does not mean
that the data controller here is responsible for its subsidiary data intermediary in the
same way as it does for its primary data intermediaries. This is because in many
scenarios, the data controller may not even be aware that its primary data intermediary
had engaged a sub-contractor, and hence it is in no position to influence its subsidiary
data intermediary. Instead, in situations where there are multiple layers of subcontracting and sub-processing of personal data, there is a separate data controller
and data intermediary relationship in each layer. The scope of data processing
outsourced in each layer of sub-contracting is determined by the relevant contract
which should also set out the data controller’s and data intermediary’s respective
obligations to protect the personal data. Therefore, even if Times was regarded as
Red Hat’s and LIU’s “subsidiary data intermediary” (not actually so in this case for the
reason set out in the preceding paragraph), Red Hat and LIU would not be responsible
for Times as if they were Times’ data controller for the purposes of the PDPA. Times’
data controller here would be TMF solely.
13

Times Software Pte Ltd & Ors

2020 SGPDPC [18]

Indeed, TMF’s role as Times’ data controller and Red Hat’s and LIU’s data

intermediary meant that TMF was subject to the Protection Obligation in putting in
place “reasonable security arrangements”, such as contractual mechanisms with
Times, to ensure that Times had the necessary safeguards to protect the Employee
Data.
33

In this regard, it is not disputed that there was no written contract between TMF

and Times regarding the processing of the Employee Data. TMF was therefore found
in breach of the Protection Obligation in the Preliminary Decision.
34

In the course of settling this decision, TMF made representations disputing the

preliminary finding that it had breached the Protection Obligation, raising the following
factors for consideration:
(a)

TMF had conducted annual vendor assessments with Times, and Times

had confirmed in those assessments that it had a formal data disposal policy in
place, which had led TMF to incorrectly believe that none of the Employee Data
was retained by Times. In the circumstances, it would not be reasonable to
expect TMF to conduct an invasive audit of Times’ IT system to verify that the
Employee Data was absent; and
(b)

TMF did not ask Times to retain and use the Employee Data for the

development of a new functionality within the Payroll Software. Times had done
do without TMF’s authorisation, and was not acting as TMF’s data intermediary
in doing so. Accordingly, TMF should not be held responsible for Times secret
retention of the Employee Data.
35

While TMF’s conduct of the annual vendor assessments is a mitigating factor

that is taken into account, it does not suffice to discharge TMF’s Protection Obligation.
The annual vendor assessments would only assist to check that Times had not
retained the Employee Data unnecessarily. However, it bears repeating here that TMF
had not entered into any contract with Times with respect to Time’s processing of Red
Hat’s and LIU’s Employee Data on TMF’s behalf. This means that the purpose and
14

Times Software Pte Ltd & Ors

2020 SGPDPC [18]

scope of the processing to be undertaken by Times, as well as Times’ obligation to
protect the relevant Employee Data, were not clearly set out in the first place.
36

On this note, the grounds for finding that TMF had breached the Protection

Obligation is primarily due to TMF’s failure to put in place the necessary contractual
provisions requiring Times to protect Red Hat’s and LIU’s Employee Data prior to the
transmission of the data during the one-time data migration exercise. Hence, it is not
necessary to make a finding on whether Times had used the Employee Data for the
development of the new functionality tool. As mentioned at [4] above, TMF disputes
this account and there was insufficient contemporaneous evidence to support either
party’s version of events.
37

Having carefully considered the facts of the case, the finding that TMF had

contravened the Protection Obligation was maintained. After taking into account the
relevant mitigating and aggravating factors listed at [44] below, it was determined that
a warning to TMF for the breach would suffice in this case.
No Breach by Red Hat and LIU
38

For Red Hat and LIU, the question to be determined is whether they had taken

“reasonable security arrangements” to protect their Employee Data when they
provided the Employee Data to TMF for processing.
39

Red Hat and LIU had both entered into a written contract with TMF for the

processing of their Employee Data. Both contracts were similarly worded and imposed
a general obligation on TMF to comply with the “applicable law”, with no express
reference to compliance with the PDPA. Both Red Hat and LIU were found to have
contravened the Protection Obligation in the Preliminary Decision because in addition
to an “applicable law” clause, they ought to have put in place more detailed contractual
provisions setting out TMF’s obligations to protect the Employee Data (which included
bank account and salary information).

Times Software Pte Ltd & Ors

2020 SGPDPC [18]

In the course of settling this decision, Red Hat made representations disputing

the preliminary finding that it had breached the Protection Obligation, and raised the
following factors for consideration:
(a)

Although the contract between Red Hat and TMF imposed only a general

obligation on TMF to comply with the “applicable law”, there should be no
ambiguity that the applicable data protection law is the PDPA given that both Red
Hat and TMF are incorporated in Singapore; and
(b)

The contract between Red Hat and TMF had to be read together with

the Master Services Agreement (“MSA”) between their parent companies. The
MSA contained two pertinent clauses on data protection:
“TMF and its Affiliates shall use at least the same degree of care to
protect the Confidential Information of Client and its Affiliations from
unauthorised disclosure or access that TMF and its Affiliates use to
protect its Confidential Information but not less than reasonable care”
(Clause 10.4 of the MSA); and
“[T]he processing and global transmission of Data shall comply with
Applicable Law which includes among others the binding corporate rules
of TMF on international data transfers” (Clause 11.2 of the MSA).
41

The provisions in the MSA meant that TMF was contractually bound to protect

the Employee Data of Red Hat with the same standard of care as its own data, and in
any case, not less than reasonable care. TMF’s internal data protection policies are
therefore relevant in assessing the standard of protection that it was contractually
required to put in place. In this regard, TMF’s: (i) Personal Data Protection Policy; (ii)
General Data Protection Regulation Statement; and (iii) Binding Corporate Rules for
processing customer data set out comprehensive requirements on data protection.
42

The inclusion of such terms in the contracts between TMF and Red Hat are

adequate to satisfy the “reasonable security arrangements” requirement in Section 24

Times Software Pte Ltd & Ors

2020 SGPDPC [18]

of the PDPA. Accordingly, Red Hat had not contravened its obligations under Section
24 of the PDPA.
43

Similarly, the contract between LIU and TMF, read together with the MSA also

incorporated TMF’s Personal Data Protection Policy, General Data Protection
Regulation statement and Binding Corporate Rules for processing customer data. For
the same reasons set out at [40] and [41] above, it follows that the terms in the
contracts between TMF and LIU are adequate to satisfy the “reasonable security
arrangements” requirement in Section 24 of the PDPA. Accordingly, LIU had also not
contravened its obligations under Section 24 of the PDPA.
The Commissioner’s Directions
44

In determining the directions to be imposed on Times, Dentons, and TMF under

Section 29 of the PDPA, the following factors were taken into account:
(a)

In respect of Times:
Mitigating Factors
(i)

It has implemented remedial actions to address the deficiencies

that caused the Incident; and
(ii)

It was cooperative in the course of investigation and had provided

prompt responses to the Commission’s requests for information; and
Aggravating Factor
(i)

The Employee Data was of a sensitive nature, and should have

warranted more careful processing.
(b)

In respect of Dentons:
Mitigating Factors

Times Software Pte Ltd & Ors

(i)

2020 SGPDPC [18]

The Employee Data was provided to Times for a one-time

transaction, and the processing by Times was not expected to be of an
ongoing nature;
(ii)

It had voluntarily reported the breach;

(iii)

It had not directly caused the Incident;

(iv)

It had implemented remedial actions to address the Incident; and

(v)

It had fully cooperated with the Commission in its investigations

and had provided prompt responses to the Commission’s requests for
information; and
Aggravating Factor
(i)

The personal data which was subject to the Incident included

bank account and/or salary information which ought to have been
protected to a higher standard.
(c)

In respect of TMF:
Mitigating Factors
(i)

The Employee Data was provided to Times for a one-time

transaction, and the processing by Times was not expected to be of an
ongoing nature;
(ii)

had

acted

responsibly

conducting

annual

vendor

assessments of Times;
(iii)

It had not directly caused the Incident;

(iv)

It had implemented remedial actions to address the Incident; and

Times Software Pte Ltd & Ors

(v)

2020 SGPDPC [18]

It was cooperative in the course of investigation and had provided

prompt responses to the Commission’s requests for information; and
Aggravating Factor
(i)

The personal data which was subject to the Incident included

bank account and salary information which ought to have been protected
to a higher standard.
45

To summarise, the Commissioner directed:
(a)

Times to pay a financial penalty of $20,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;

(b)

A warning to be given to Dentons in lieu of a financial penalty; and

(c)

A warning to be given to TMF in lieu of a financial penalty.

No further directions are necessary given the remediation measures already put

in place by the organisations involved.

MICHELLE YAP
ASSISTANT COMMISSIONER
FOR COMMISSIONER FOR PERSONAL DATA PROTECTION

",Financial Penalty,976a574a38eb0225fbf7a43d418a4b5c6717efc8
80,80,1,952,"A financial penalty of $120,000 was imposed on Secur Solutions Group for failing to put in place reasonable security arrangements to protect a database containing the personal data of blood donors from being publicly accessible online.","[""Protection"", ""Financial Penalty"", ""Professional"", ""Scientific and Technical"", ""Database"", ""Gaps"", ""Public access""]",2020-11-24,https://www.pdpc.gov.sg/-/media/Files/PDPC/PDF-Files/Commissions-Decisions/Decision---Secur-Solutions-Group-Pte-Ltd---30032020.pdf,Protection,Breach of the Protection Obligation by Secur Solutions Group,https://www.pdpc.gov.sg/all-commissions-decisions/2020/11/breach-of-the-protection-obligation-by-secur-solutions-group,2020-11-24,"PERSONAL DATA PROTECTION COMMISSION

[2020] SGPDPC 8

Case No DP-1903-B3501

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

And

Secur Solutions Group Pte Ltd

… Organisation

DECISION

Secur Solutions Group Pte Ltd

[2020] SGPDPC 8

Secur Solutions Group Pte Ltd
[2020] SGPDPC 8

Tan Kiat How, Commissioner — Case No DP-1903-B3501
30 March 2020

Introduction
1

This case relates to an incident where one of Secur Solutions Group Pte

Ltd’s (the “Organisation”) servers, which stored a database (the “Database”)
containing personal data of blood donors, was discovered to be accessible from
the internet (the “Incident”).
2

The Personal Data Protection Commission (the “Commission”)

received a formal request from the Organisation requesting for this matter to be
handled under the Commission’s Expedited Breach Decision procedure. In this
regard, the Organisation voluntarily provided and unequivocally admitted to the
facts as set out in this Decision and that it was in breach of section 24 of the
Personal Data Protection Act (the “PDPA”).

Secur Solutions Group Pte Ltd

[2020] SGPDPC 8

Facts of the Case
3

The Organisation has been engaged by the Health Sciences Authority

(“HSA”) since 2013 to develop and maintain various IT systems. One of the
projects for which the Organisation was engaged was the development,
maintenance and enhancement of its queue management system (“ QMS”) for
blood donors (the “QMS Engagement”). Pursuant to the QMS Engagement,
HSA provided the Organisation with files containing copies (in part or
otherwise) of the Database (“Files”) for the purposes of testing and developing
the QMS. HSA would also provide the Organisation with copies or updates of
the Database (“Updates”) from time to time during the period of the QMS
Engagement (hereinafter, the use of the phrase “Files” will include “Updates”,
unless the context specifies otherwise).
4

The Organisation stored the Files in a storage server that was designated

for the purposes of testing and development (the “Testing and Development
Server”). The Testing and Development Server was accessible through the
Internet and unsecured as it was not intended to be used to store personal data
or other confidential information. The Server’s system was not actively patched
or updated, the router to which the Server was connected did not have a
perimeter firewall setup, and there were no firewalls or any other security
protocols to restrict access to the Server.
5

At the material time, the Files contained registration-related information

(the “Personal Data”) of about 800,000 individual blood donors (the “Affected
Individuals”), specifically:
(a)

Name;

(b)

NRIC;

Secur Solutions Group Pte Ltd

[2020] SGPDPC 8

(c)

Gender;

(d)

Handphone number1;

(e)

Number of blood donations;

(f)

Dates of the last 3 blood donations; and

(g)

(In some cases) blood type, height and weight.

A cybersecurity expert discovered that he could access the Personal Data

in the Database through one of the Organisation’s servers. Based on the forensic
investigations conducted by the Organisation, the number of records from the
Database that had been exfiltrated amounted to anywhere between 236,023 to
328,546.
7

Upon being notified of the Incident on 13 March 2019, the Organisation

took the following remedial actions:
(a)

Disconnected the Testing and Development Server from the

Internet and removed all physical devices connected to the compromised
ports to the server;
(b)

Disabled all remote access to the Organisation’s servers to

ensure that all development zones were protected by firewalls;
(c)

Organised an employee townhall session addressing the

Incident;

1This was based on the information provided by the Organisation.

Secur Solutions Group Pte Ltd

(d)

[2020] SGPDPC 8

Appointed external vendors to undertake forensic analysis of the

affected servers;
(e)

Issued press releases to keep the public informed of the Incident

and the status of ongoing investigations;
(f)

Informed its employees not to receive personal data from clients

if it was not necessary and to escalate the receipt of personal data
(inadvertently or otherwise) to senior management;
(g)

Conducted further investigation on the security of its Internet

lines and Internet-facing services;
(h)

Began reviewing and improving its internal processes and taking

steps to enhance its cybersecurity posture, including appointing a second
Data Protection Officer, requiring employees to complete an e-learning
program and identifying and remediating any gaps in protection; and
(i)

Began reviewing its security infrastructure with the assistance of

an external vendor, and implementing certain measures, including (i)
ensuring all devices used by employees are secured and the anti-virus
software installed on these devices are up-to-date, (ii) implementation
of a Network Access Control measure, (iii) adoption of a “defence-indepth” approach (including segregation of servers containing sensitive
information) and (iv) enhancement of endpoint security measures.

Findings and Basis for Determination

Secur Solutions Group Pte Ltd

[2020] SGPDPC 8

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. As a preliminary point, the
Organisation has accepted that it is a data intermediary of HSA and is required
to comply with section 24 of the PDPA with respect to the Personal Data in its
possession.
Whether the Organisation Complied with Section 24
9

The Organisation has admitted that it has breached section 24 of the

PDPA by failing to put in place reasonable security arrangements to protect the
Personal Data.
10

The Organisation informed the Commission that it had stored the Files

containing the Database in its Testing and Development Server as it did not
anticipate that it would be receiving actual copies of production databases from
HSA and, as such, did not take any steps to designate any specific security
infrastructure set up to receive or store such data on premise.
11

The Organisation admitted that it ought to have been aware that the Files

contained personal data even though they had not been specifically informed of
this by HSA. In past projects between them, the Organisation had directly
retrieved personal data from a production environment on the servers on HSA’s
premises for the purposes of testing and development. On this occasion, even
though the Files were provided by HSA to the Organisation for the QMS
Engagement, from July to August 2018, the Organisation was given access to
HSA’s server rooms to retrieve Updates directly from HSA’s servers, an
arrangement that made sense if the Files also contained actual personal data (as

Secur Solutions Group Pte Ltd

[2020] SGPDPC 8

opposed to dummy data). Accordingly, the Organisation ought to have been
aware that personal data was contained in the Files, but most definitely in the
Updates.
12

In this regard, the Organisation admitted that the Files should not have

been stored on the Testing and Development Server, and this was a breach of
the Organisation’s own data protection policies and practices, which required
that personal data be protected and secured regardless of the purposes for which
it was provided.
13

The Organisation has accepted that there were gaps in its data

governance and processes with respect to the receipt of test data from its clients.
14

In view of the above, the Commissioner found the Organisation in

breach of section 24 of the PDPA.
Representations by the Organisation
15

In the course of settling this decision, the Organisation made

representations to request that the financial penalty as set out in [19] be paid in
the following manner:

(a)

$60,000 within 30 days from the date of the directions; and

(b)

$60,000 within 7 months from the date of the directions.

The Organisation raised the following factors for the Commissioner’s

consideration:
(a)

The Organisation is a small medium enterprise in a highly
competitive IT services industry. It has to contend with rising

Secur Solutions Group Pte Ltd

[2020] SGPDPC 8

wage costs and increased rentals while battling depressed prices
that customers are willing to pay for their services;
(b)

Arising out of the Incident, the Organisation has:
(i)

Expended significant resources when it appointed

reputable advisors to undertake forensic activities, and sought the
advice and assistance of professionals to respond to the police and
the Commission’s investigations;
(ii)

Invested heavily to shore up its data protection and

cybersecurity measures, including conducting research and
exploring various technologies and methods which may be
deployed in protecting data (at rest and in transit) without
compromising ease of use of the data; and
(c)

Payment of the entire financial penalty of $120,000 in one lump
sum would negatively affect the Organisation’s cash flow.

Having carefully considered the representations, the Commissioner has

decided to reject the Organisation’s request at [15]. For the purposes of
supporting a request that a financial penalty be paid in instalments,
organisations are required to furnish supporting documents on their financial
status to the Commission. However, despite the Commission’s repeated
requests, the Organisation did not furnish its financial statements and was
unable to provide any explanation why it could not to do so. There was therefore
no evidence to support the Organisation’s representations on its financial status
at [16]. If the Organisation is able to secure documentary evidence of its
financial position before the due date for payment as set out at [19], it may
submit another request that the financial penalty be paid in instalments.

Secur Solutions Group Pte Ltd

[2020] SGPDPC 8

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
factors:
Mitigating factors
(a)

The Organisation was cooperative during the Commission’s

investigations;
(b)

As set out above, the Organisation voluntarily and unequivocally

admitted to its contravention of the PDPA; and
(c)

The Organisation implemented remedial actions swiftly to

address the Incident; and
Aggravating Factor
(d)

A subset of the Personal Data was subject to unauthorised access

and exfiltration.
19

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

Commissioner hereby directs the Organisation to pay a financial penalty of
$120,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.
20

The Commissioner took the view that the remedial actions set out at

paragraph [7] had sufficiently addressed the risks to the Personal Data arising

Secur Solutions Group Pte Ltd

[2020] SGPDPC 8

from the Incident. The Commissioner has therefore not set out any further
directions for the Organisation.

YEONG ZEE KIN
DEPUTY COMMISSIONER
FOR COMMISSIONER FOR PERSONAL DATA PROTECTION

",Financial Penalty,aa05055fb8dd4b8379487aa1343e9e005c42257d
81,81,1,952,"Directions, including a financial penalty of $7,500 were imposed on Majestic Debt Recovery for failing to obtain consent from its debtors to record the debt collection process. Majestic Debt Recovery also did not obtain consent to upload the recordings onto its Facebook Page. Additionally, Majestic Debt Recovery did not have written policies and practices necessary to ensure its compliance with the PDPA.","[""Protection"", ""Accountability"", ""Directions"", ""Financial Penalty"", ""Others"", ""Consent"", ""No DPO"", ""No Policy""]",2020-11-24,https://www.pdpc.gov.sg/-/media/Files/PDPC/PDF-Files/Commissions-Decisions/Decision---Majestic-Debt-Recovery---02032020.pdf,"Protection, Accountability",Breach of the Consent and Accountability Obligations by Majestic Debt Recovery,https://www.pdpc.gov.sg/all-commissions-decisions/2020/11/breach-of-the-consent-and-accountability-obligations-by-majestic-debt-recovery,2020-11-24,"PERSONAL DATA PROTECTION COMMISSION

[2020] SGPDPC 7
Case No DP-1903-B3570

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

And

Majestic Debt Recovery Pte Ltd

… Organisation

DECISION

Majestic Debt Recovery Pte Ltd
[2020] SGPDPC 7

Yeong Zee Kin, Deputy Commissioner — Case No DP-1903-B3570
2 March 2020

Introduction
1

This case concerns a debt collection company’s posting of a video recording on social

media as a tactic to shame a debtor. The recordings in question captured exchanges between
the company’s representative and staff of the debtor company.
Facts of the Case
2

Majestic Debt Recovery Pte Ltd (the “Organisation”) is a company in the business of

collecting debts on the behalf of its clients. On 22 March 2019, the Personal Data Protection
Commission (the “Commission”) received a complaint from the managing director (the
“Complainant”) of a debtor company (the “Company”) stating that the Organisation had been
engaged by the Company’s sub-contractor to recover debts from the Company. The
Complainant stated that on or around 21 March 2019, the Organisation’s representatives (the
“Representatives”) visited the Company’s premises to collect a debt on behalf of its client (the
“Incident”). Not surprisingly, heated words were exchanged with the Company’s personnel
when the Representatives attempted to recover the debt. The Representatives recorded video
footage of the exchanges with the Company’s personnel, including the Complainant (the
“Recording”), on a tablet device. The Complainant and the Company’s personnel could be
identified from the images and audio captured by the Recording. According to the
Complainant, he “protested against the taking of [the Recording and] posting it [on] social
media but [the Representative] said he would do it”. The Representatives nonetheless took the
Recording and subsequently posted it on the Organisation’s official public Facebook page (its
“Facebook Page”).

During its investigation, the Commission found other video recordings on the

Facebook Page. These videos also captured images and voices of other individuals who
appeared to be either individual debtors or representatives of corporate debtors of the
Organisation’s clients.
4

By its own admission to the Commission, the Organisation did not have any knowledge

of the Personal Data Protection Act 2012 (“PDPA”) prior to this incident and had not
developed any data protection policies or practices. The Organisation also admitted that it did
not have a data protection officer (“DPO”) prior to this incident.
5

Upon being notified by the Commission, the Organisation took the following remedial

actions:
(a)

Removed the Recording and all other videos from the Facebook Page;

(b)

Designated an individual tasked with data protection matters (i.e. a DPO); and

(c)

Assured the Commission that it will ensure that it obtains consent in writing

from individuals before recording and uploading their personal data onto its Facebook
Page.
Findings and Basis for Determination
Whether the Organisation had breached section 13 of the PDPA
6

Broadly, section 13 of the PDPA prohibits organisations from collecting, using or

disclosing personal data about an individual unless the individual’s consent is obtained (either
actual or deemed) or such collection, use or disclosure is required or authorised under the PDPA
or any written law. As stated at [2], the Organisation recorded the video using a tablet device.
The incident took place at the Company’s premises, after the Representatives were met at the
reception and brought into the office proper, which was not open to the public. The
Organisation posted the Recording on its Facebook Page despite the Complainant’s protests.
This disregard of the individual’s wishes is a breach of section 13 of the PDPA given that the
collection, use and disclosure of the Recording was not required or authorised under the PDPA
or other written law.

In relation to the Organisation’s assurance (noted at [5]) that it would in future obtain

consent from individuals concerned, it seems unlikely or even unconceivable that an individual
who owed a debt would willingly consent to be filmed by the debt collecting agency calling on
him, and for such recordings to be posted on social media. If such consent were obtained ex
ante by an organisation, for example at the time when the loan was first given, and the purpose
for posting the recording on social media is to shame the debtor, there is a real risk that this
purpose may not be one which a reasonable person would consider appropriate under section
18 of the PDPA; or that consent thus obtained is vitiated under section 14(3), as having been
obtained through unfair, or deceptive or misleading practices.
8

However, this is not to say that the capturing of personal data through video will never

be appropriate or in compliance with the PDPA. As an example, a security company may wish
to equip its security officers with body worn cameras to ensure that its officers are exercising
their duties in a responsible and lawful manner and their interactions with the public adhere to
their code of conduct. Any organisation that wishes to implement such a practice has to be
accountable and should ensure that it has sound legal basis to do so. Additionally, it will need
to put clear guidelines and policies in place for its employees in relation to their conduct and
the use of such cameras and the video footage captured. In developing such guidelines and
policies, such organisations should ensure that the use of these recording devices are in
compliance with the PDPA and have measures and controls in place to ensure that these
guidelines and policies are adhered to.
Whether the Organisation had breached sections 12 and 11(3) of the PDPA
9

Section 12 of the PDPA requires organisations to, inter alia, develop and implement

policies and practices that are necessary for the organisation to meet its obligations under the
PDPA, and section 11(3) of the PDPA requires organisations to designate one or more
individuals (i.e. the DPO) to be responsible for ensuring the organisations’ compliance with
the PDPA.
10

By nature of its business, the Organisation would be in possession and/or control of

various personal data, including those of its employees and its clients’ debtors or the debtors’
employees. As stated at [3], the Organisation admitted that it did not have any knowledge of

the PDPA prior to being notified by the Commission over this incident, did not have any data
protection policies or practices, and had not appointed a DPO.
11

In light of the foregoing, the Organisation was also in breach of sections 11(3) and 12

of the PDPA.
Representations by the Organisation

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

the findings as set out at [6]. The Organisation raised the following factors:
(a)

When the Representatives visited the Company to recover debts on various

occasions prior to the Incident they had made video recordings of those visits without
any objections from the Company; and
(b)

According to the Organisation, it had “video proof” of the Complainant

consenting to the Organisation posting video recordings of the Representative’s visits
to the Company on its Facebook Page.
13

Having carefully considered the representations, I maintain the finding that the

Organisation was in breach of Section 13 of the PDPA for the following reasons:
(a)

The Organisation was unable to provide any evidence to support its assertion

that there had been consent by the Company on previous occasions to the Organisation
video recording the Representatives’ visits to the Company’s premises. The
Organisation was also unable to provide the “video proof” referred to at [12(b)];
(b)

Even if consent had been obtained previously, section 16(1) of the PDPA

provides that on giving reasonable notice to the organisation, an individual may at any
time withdraw any consent given, or deemed to have been given in respect of the
collection, use or disclosure by that organisation of personal data about the individual
for any purpose. As mentioned at [2], the Complainant had expressly objected to the
video recording and the subsequent posting of the video on the Facebook Page. In the
circumstances, I find that even if consent was given previously as asserted by the
Organisation at [12], it had been withdrawn by virtue of the Complainant’s express
5

objections at the material time. Accordingly, the Organisation did not have consent to
post the Recording on its Facebook Page; and
(c)

Furthermore, even if consent had been obtained to post the video recording on

social media to shame the debtor, I have grave doubts if the consent will stand up to
scrutiny under section 14(2) of the PDPA, which vitiates consent obtained through
unfair, and deceptive or misleading practices. For example, if consent to post video
recordings made during debt recovery attempts was made a condition of obtaining the
loan, it could possibly go beyond what is reasonable in order to provide the loan: see
section 14(2)(a). Consent obtained through such unfair practice is vitiated by section
14(3). Neither would such a purpose be one which a reasonable person — on an
objective standard — would likely consider to be appropriate under section 18 of the
PDPA.
The Deputy Commissioner’s Directions
14

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

PDPA, I took into account the following mitigating factors:
(a)

the Organisation was cooperative and forthcoming in the course of

investigations;
(b)

the Organisation took prompt remedial action after being notified by the

Commission; and
(c)

there was no evidence of any further unauthorised use of the personal data

captured in the Recording.
15

Having carefully considered all the relevant factors of this case, I hereby direct the

Organisation to:
(a)

pay a financial penalty of $7,500 within 30 days from the date of this direction,

(b)

develop and implement policies and practices which are necessary for its

compliance with the PDPA; and
(c)

put in place a program of compulsory training for its employees on compliance

with the PDPA.

YEONG ZEE KIN
DEPUTY COMMISSIONER
FOR PERSONAL DATA PROTECTION

","Directions, Financial Penalty",735c56aebf1838696565bb02754125b665e3d968
82,82,1,952,Directions were issued to Security Masters for failing to put in place reasonable security arrangements to prevent the unauthorised access of building visitors’ mobile numbers. A security personnel contacted the visitors to request return of visitor passes and send them Chinese New Year greetings.,"[""Protection"", ""Directions"", ""Others"", ""Text messages"", ""Mobile numbers"", ""Protection""]",2020-10-16,https://www.pdpc.gov.sg/-/media/Files/PDPC/PDF-Files/Commissions-Decisions/Decision---Security-Masters-Pte-Ltd---21072020.pdf,Protection,Breach of the Protection Obligation by Security Masters,https://www.pdpc.gov.sg/all-commissions-decisions/2020/10/breach-of-the-protection-obligation-by-security-masters,2020-10-16,"PERSONAL DATA PROTECTION COMMISSION
Case No. DP-2002- B5875
In the matter of an investigation under section 50(1) of the
Personal Data Protection Act 2012
And
Security Masters Pte Ltd

SUMMARY OF THE DECISION
1.

On 17 February 2020, Security Masters Pte Ltd (the “Organisation”) notified the
Personal Data Protection Commission (the “Commission”) that a security employee had
used the mobile phone numbers of eight building visitors to contact them to request their
return of visitor passes and send them Chinese New Year greetings.

Investigation found that the Organisation did not put in place any standard operating
procedure or guidelines for the retrieval and use of visitors’ personal data prior to the
incident. This gap in security arrangements allowed the incident to occur.

Following the incident, the Organisation restricted access to personal data to senior
personnel and required all security personnel to sign an undertaking not to contact visitors

in their personal capacity. However, structured training is needed to help its security
personnel understand the importance of protecting the personal data they handled daily
in their duties, such as National Registration Identification Card numbers, photographs
and closed-circuit television footage.

On the above consideration, the Deputy Commissioner for Personal Data Protection
hereby directs the Organisation to:

a) Within 60 days from the date of the direction, revise its training curriculum to ensure

that its security personnel understand
i.

the rationale for personal data protection;

ii.

the importance of consent and authorisation in the handling of personal data;
and

iii.

the circumstances in which it would be appropriate to use and disclose
personal data on social media platforms for work-related purposes; and

b) Inform the Commission within 1 week of implementation of the above.

",Directions,e24e6989567857bec320cd7ad6365fd535330a52
83,83,1,952,A warning was issued to Interauct! for retaining personal data which was no longer necessary for legal or business purposes.,"[""Retention Limitation"", ""Warning"", ""Others"", ""Backup files"", ""Server migration""]",2020-10-16,https://www.pdpc.gov.sg/-/media/Files/PDPC/PDF-Files/Commissions-Decisions/Decision---Interauct-Pte-Ltd---04082020.pdf,Retention Limitation,Breach of the Retention Limitation Obligation by Interauct!,https://www.pdpc.gov.sg/all-commissions-decisions/2020/10/breach-of-the-retention-obligation-by-interauct,2020-10-16,"PERSONAL DATA PROTECTION COMMISSION
Case No. DP-1911-B5268
In the matter of an investigation under section 50(1) of the
Personal Data Protection Act 2012
And
Interauct! Pte Ltd

SUMMARY OF THE DECISION
1. Interauct! Pte Ltd (the “Organisation”) operated an online mobile number auction (the
“Auction”) for a telecommunications provider (the “Telco”). This arrangement started in
the year 2000 and ended in 2018.

2. In November 2019, the Commission was informed that the Telco’s cybersecurity team had
located an internet sub-domain containing files with the personal data of individuals who
had participated in the Auction (the “Files”). The Files contained the following types of
personal data:
a. Name;
b. ID (such as passport or NRIC number);
c. Mobile number;
d. Address;
e. Date of birth; and
f. Email address.

3. The Commission’s investigations revealed the following:

a. The Organisation had engaged a vendor to provide web hosting services for the
Auction. In 2012 and 2016, the vendor conducted server migration exercises. On both
occasions, the Organisation created backups of the Files prior to server migration
exercises and uploaded them on the vendor’s servers. The Organisation did not delete
the Files after the server migration were completed;

b. In April 2019, the vendor misconfigured its servers. As a result, the Files became
accessible on the internet sub-domain. However, to access this sub-domain requires
an individual to key in either one of two URLs exactly. Both URLs were complex
and lengthy. It was therefore difficult for an individual to determine the URLs exactly
to enter the sub-domain. Indeed, an examination of server logs found that only the
Telco had accessed the sub-domain;

c. The Files contained a mix of individuals’ personal data, as well as dummy data used
for testing purposes. An analysis of the Files showed that there were approximately
8,750 individuals’ personal data contained in them. The Telco compared the data with
its customer records, and via a reconciliation process, was able to identify 3,380
individuals as its customers. In this regard, the Telco informed that it would have
been very difficult for a third party, without access to the Telco’s customer records,
to carry out such a reconciliation exercise. This means that even if an individual had

accessed the Files, it would have been difficult to him to identify the individuals from
the personal data in the Files;

d. The Organisation deleted the Files within three hours of the Telco notifying the
Organisation of their discovery of the internet sub-domain. The Organisation had also
ensured that the vendor fixed the misconfiguration of the servers, which was done
within six hours of the discovery of the internet sub-domain.

4. The Deputy Commissioner for Personal Data Protection (the “Deputy Commissioner”)
finds that the Organisation had put in place, via the vendor, reasonable security
arrangements to protect the personal data. In particular, the security arrangements in place
would have prevented direct access by unauthorised third-parties to the Files hosted on the
server. This had greatly reduced the potential adverse impact of the incident.

5. However, the Organisation admitted that there was no reason to retain the Files after the
migration exercises were completed. If the Files had been duly deleted, the personal data
in the Files would not have been compromised in the first place. The Deputy Commissioner
therefore finds the Organisation in breach of the Retention Limitation Obligation under
section 25 of the Personal Data Protection Act 2012.

6. After considering the facts and circumstances of the incident, including the fact that the
personal data in the Files was ultimately not exposed, the Deputy Commissioner has

decided to issue a warning to the Organisation for the breach of the Retention Limitation
Obligation. No other direction is required as the breach has been remedied.

",Warning,5932047a3ee552243babdc8b5564ced3e448d87b
84,84,1,952,"A warning was issued to Chan Brothers Travel for failing to put in place reasonable security arrangements to protect the personal data of individuals on its website. The result was that the personal data of over 5,500 individuals were accessible through online web search engines.","[""Protection"", ""Warning"", ""Arts, Entertainment and Recreation"", ""Access control"", ""SEO indexing""]",2020-10-16,https://www.pdpc.gov.sg/-/media/Files/PDPC/PDF-Files/Commissions-Decisions/Decision---Chan-Brothers-Travel-Pte-Ltd---21072020.pdf,Protection,Breach of the Protection Obligation by Chan Brothers Travel,https://www.pdpc.gov.sg/all-commissions-decisions/2020/10/breach-of-the-protection-obligation-by-chan-brothers-travel,2020-10-16,"PERSONAL DATA PROTECTION COMMISSION
Case No. DP-1905-B3936
In the matter of an investigation under section 50(1) of the
Personal Data Protection Act 2012
And
Chan Brothers Travel Pte Ltd

SUMMARY OF THE DECISION
1.

On 23 May 2019, the Personal Data Protection Commission (the “Commission”)
received a data breach notification from Chan Brothers Travel Pte Ltd (the
“Organisation”) and a complaint from a member of the public. Both were in relation to
personal data being at risk of unauthorised access through the Organisation’s website at
http://chanbrotherstravelclub.force.com (the “Website”) (the “Incident”).

In March 2017, the Organisation purchased Community Cloud, a product of
Salesforce.com Singapore Pte Ltd (“Salesforce”), to host the Website. The Organisation
managed the Website internally. In August 2018, the Organisation engaged Aodigy Asia
Pacific Pte Ltd (“Aodigy”) as an outsource vendor to maintain and improve the Website.

The Website provided three online forms for enquiries and feedback. These were the
“Enquiry Form”, Feedback Form” and “Post-Tour Feedback Form” (collectively the
“Forms”). The Forms collected the users’ names, email addresses and mobile phone
numbers.

In March 2018, there was a software update released by Salesforce for Community
Cloud. This software update included an automated search engine optimisation feature
(the “SEO”). As the Website’s access configuration was set to “Public”, the Forms
automatically inherited the same setting for the purpose of the SEO feature. The result
was that the personal data of an estimated 5,593 individuals collected by the Forms were
indexed and cached, and made searchable, through online web search engines.

Organisations that employ IT systems or features are responsible for data security.
Organisations must acquire knowledge of the security settings and be aware of security
implications of software features of their IT system, and they must configure the security
settings to enable effective protection of personal data stored in the IT system. This
responsibility extends to new features introduced by subsequent software releases.
Organisations that lack the IT knowledge to discharge this responsibility should engage
qualified assistance.

The Organisation failed to consider the implication of the “Public” setting of the Website
on the security of the data collected by the Forms. It also failed to understand the function
and operation of the SEO feature. The combination of these acts of omission resulted in
the security issues arising leaving the SEO feature enabled.

The Organisation claimed not to have received any notification from Salesforce of the
SEO release. However, this is contradicted by the following. First, the notes of the
software release was published on the website of Salesforce. Second, Aodigy had (in its
role as vendor for another project) received information of the release. On balance, it is

therefore unlikely that Salesforce would have omitted to notify the Organisation about
the software release. In any event, the software release was in March 2018 when the
Organisation was still maintaining the Website internally. The responsibility to assess
the security implications of the software release laid squarely on its shoulders during that
5-month period before Aodigy was engaged.

Further, there is some uncertainty over whether Aodigy was instructed to review the
security configuration of the Website (including the new software features) as part of its
maintenance services when it was engaged. The Organisation did not give clear
instructions to Aodigy to assess the security configuration of the IT system as part of the
maintenance services.

In the circumstances, the Deputy Commissioner for Personal Data Protection therefore
found the Organisation in breach of section 24 of the Personal Data Protection Act 2012
and took into account the following factors in deciding to issue a Warning to the
Organisation:

a. The personal data at risk of disclosure was limited to names, email address and
contact numbers, apart from an estimated 50 NRIC numbers.

b. The Organisation voluntary notified the Commission of the Incident.
c. Prompt co-operation in the course of the Commission’s investigations.

10.

No directions are required as the Organisation took immediate steps to prevent the
recurrence of the Incident.

",Warning,1371e96aee9b5458d29ef161ea0de43abb7b1200
85,85,1,952,"A financial penalty of $4,000 was imposed on Tanah Merah Country Club for failing to put in place reasonable security arrangements to protect the personal data of individuals stored on its electronic direct mail (“EDM”) system. The common password for login to the EDM system was weak and had not been changed since 2010. There were also no arrangements in place to ensure and enforce password strength, expiry and protection. An application for reconsideration was filed against the decision Re Tanah Merah Country Club. Upon review and careful consideration of the application, directions in the decision were varied.","[""Protection"", ""Financial Penalty"", ""Arts, Entertainment and Recreation"", ""EDM"", ""Password"", ""Weak password""]",2020-10-16,https://www.pdpc.gov.sg/-/media/Files/PDPC/PDF-Files/Commissions-Decisions/Decision---Tanah-Merah-Country-Club---21072020.pdf,Protection,Breach of the Protection Obligation by Tanah Merah Country Club,https://www.pdpc.gov.sg/all-commissions-decisions/2020/10/breach-of-the-protection-obligation-by-tanah-merah-country-club,2020-10-16,"PERSONAL DATA PROTECTION COMMISSION
Case No. DP-1906-B4115
In the matter of an investigation under section 50(1) of the
Personal Data Protection Act 2012
And
Tanah Merah Country Club

Editorial note: An application for reconsideration was filed against the decision in Re
Tanah Merah Country Club. Pursuant to this application, the Commissioner has decided
to reduce the financial penalty imposed on the Organisation from $8,000 to $4,000. As the
application did not give rise to significant legal or factual issues, a separate decision on
the application will not be published.

SUMMARY OF THE DECISION

On 19 June 2019, Tanah Merah Country Club (the “Organisation”) informed the
Personal Data Protection Commission (the “Commission”) of unauthorised access to its
electronic direct mail (“EDM”) system (the “Incident”). During the Incident, which
occurred on 9 June 2019, the EDM system was used to send unauthorised spam emails.

The Organisation was unable to determine how unauthorised access was gained to the
EDM system. During investigations, it was discovered that the common password for
login to the EDM system was weak, as it comprised the initials of the Organisation and
the year 2010 (which was the year that the EDM system was set up). The password was
shared by at least 3 persons: 2 of the Organisation’s marketing staff and its technical
support vendor. Further, it had not been changed since 2010. Investigations disclosed that
there were no arrangements in place to ensure and enforce password strength, expiry and
protection.

In the circumstances, although the means of unauthorised access to the EDM system was
not determined, the evidence pointed to weak password control as the cause. The Deputy
Commissioner for Personal Data Protection therefore found the Organisation in breach
of section 24 of the Personal Data Protection Act 2012.

The Organisation is directed to pay a financial penalty of $8,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 the
financial penalty until the financial penalty is paid in full. In view of the remedial
measures taken by the Organisation, the Commission will not issue any other directions.

The Organisation’s prompt co-operation in the course of the Commission’s investigation
and its prompt actions taken to remediate the breach were taken into consideration in
determining the quantum of the financial penalty.

",Financial Penalty,e641872fa69f2e946b7cb68cb7e884c4c88db9c2
86,86,1,952,"A financial penalty of $5,000 was imposed on Vimalakirti Buddhist Centre for failing to put in place reasonable security arrangements to protect the personal data of its members and non-members from unauthorised disclosure. The incident resulted in the personal data being subjected to a ransomware attack.","[""Protection"", ""Financial Penalty"", ""Others"", ""Ransomware"", ""No measures""]",2020-10-16,https://www.pdpc.gov.sg/-/media/Files/PDPC/PDF-Files/Commissions-Decisions/Decision---Vimalakirti-Buddhist-Centre---04092020.pdf,Protection,Breach of the Protection Obligation by Vimalakirti Buddhist Centre,https://www.pdpc.gov.sg/all-commissions-decisions/2020/10/breach-of-the-protection-obligation-by-vimalakirti-buddhist-centre,2020-10-16,"PERSONAL DATA PROTECTION COMMISSION
Case No. DP-2004-B6193
In the matter of an investigation under section 50(1) of the
Personal Data Protection Act 2012
And
Vimalakirti Buddhist Centre

SUMMARY OF THE DECISION
1. On 14 April 2020, Vimalakirti Buddhist Centre (the “Organisation”) notified the
Personal Data Protection Commission (the “Commission”) of a ransomware
infection that had rendered its data management system inaccessible by the
Organisation (the “Incident”).
2. The Organisation subsequently requested for this matter to be handled under the
Commission’s expedited breach decision procedure. In this regard, the
Organisation voluntarily provided and unequivocally admitted to the facts set out
in this decision. It also admitted that it was in breach of section 24 of the Personal
Dara Protection Act (the “PDPA”).
3. The Incident occurred on or about 31 March 2020. Personal data of approximately
4,500 members and 4,000 non-members (total 8,500 individuals) were encrypted
by the ransomware. The personal data encrypted included the name, address,
contact number, NRIC number, date of birth and donation details of the individuals.
4. The Organisation admitted it did not give due attention to personal data protection,
and had neglected to implement both procedural and technical security
arrangements to protect the personal data in its possession and control.
Consequently, it did not have the relevant security software and/or protocols in
place to prevent the ransomware from entering its data management system.
5. In the circumstances, the Deputy Commissioner for Personal Data Protection finds
the Organisation in breach of the Protection Obligation under section 24 of the
Personal Data Protection Act 2012 (the “PDPA”).
6. Following the incident, the Organisation set up a new server with backup from 21
October 2019. For the data collected by the Organisation from 22 October 2019 to
the Incident, the Organisation had retrieved the data from physical file records and
restored them in the new server. It also installed a firewall to filter network traffic to
and from the new server, and cleaned, restored and reinstalled all computers

connected to its data management system. Additionally, the Organisation
committed to engage consultants to help produce a data protection manual and
train its staff in cyber hygiene and incident response.
7. The Deputy Commissioner for Personal Data Protection notes that the
Organisation had admitted to a breach of Protection Obligation under the PDPA,
cooperated with the Commission’s investigation and taken prompt remedial action.
There was no evidence that the personal data affected in the Incident had been
misused in any form. In addition, the Organisation had a backup copy of the
encrypted data and did not lose any data as a result of the Incident. Accordingly,
the practice of having data backup(s) should be encouraged to prevent
organisations from losing data in the event of ransomware.
8. On account of the above, the Deputy Commissioner for Personal Data Protection
directs the Organisation to pay a financial penalty of $5,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).
9. In view of the remedial actions taken by the Organisation, the Commission will not
be issuing any other directions.

",Financial Penalty,e0f3f4b9ea5a6f7fe98f703d2b0a529a93f64315
87,87,1,952,A warning was issued to Horizon Fast Ferry for failing to put in place reasonable security arrangements to protect the personal data in the Organisation’s email account.,"[""Protection"", ""Warning"", ""Others"", ""Password policy"", ""Email account"", ""Phishing""]",2020-10-16,https://www.pdpc.gov.sg/-/media/Files/PDPC/PDF-Files/Commissions-Decisions/Decision----Horizon-Fast-Ferry-Pte-Ltd---27082020.pdf,Protection,Breach of the Protection Obligation by Horizon Fast Ferry,https://www.pdpc.gov.sg/all-commissions-decisions/2020/10/breach-of-the-protection-obligation-by-horizon-fast-ferry,2020-10-16,"PERSONAL DATA PROTECTION COMMISSION
Case No. DP-1912-B5465
In the matter of an investigation under section 50(1) of the
Personal Data Protection Act 2012
And
Horizon Fast Ferry Pte. Ltd.

SUMMARY OF THE DECISION

The Personal Data Protection Commission (“Commission”) investigated a complaint
against Horizon Fast Ferry Pte. Ltd. (the “Organisation”) where the Organisation’s
email account, singapore@horizonfastferry.com (the “Email Account”) had sent out
phishing emails to its customers (the “Incident”).

Investigations revealed that the computer used to access the Email Account was infected
with malware. This caused the Email Account to send phishng emails to three customers.
Each email contained only the personal data that the customer himself had sent to the
Email Account to book ferry tickets. Hence there was no disclosure of other customers’
personal data in the phishing email.

The Organisation informed the Commission that it had implemented various security
measures prior to the Incident such as updating their anti-virus software regularly.
However, investigations revealed that the password to access the Email Account was

shared by 11 employees of the Organisation and had not been changed for almost 3 years.
This poor management of passwords fell short of what is reasonably required to protect
the personal data in the Email Account.

The Deputy Commissioner for Personal Data Protection therefore found that the
Organisation in breach of the Protection Obligation under section 24 of the Personal Data
Protection Act 2012 for failing to implement reasonable security arrangements to protect
the personal data in its possession or under its control. Upon consideration of the facts, a
warning was issued to the Organisation.

",Warning,a9f0d524ae6cbf14f4db5cdf1e0ccba42e45b1e0
88,88,1,952,"A warning was issued to MRI Diagnostics for failing to put in place reasonable security arrangements to prevent the unauthorised disclosure of personal data of approximately 4,099 individuals which were publicly available via the internet. Directions were imposed on Clarity Radiology for failing to appoint a data protection officer and not having policies and practices necessary to comply with the PDPA.","[""Protection"", ""Warning"", ""Healthcare"", ""Excel spreadsheet"", ""Access restriction"", ""Patching"", ""Policies""]",2020-10-16,https://www.pdpc.gov.sg/-/media/Files/PDPC/PDF-Files/Commissions-Decisions/Decision---MRI-Diagnostics-Pte-Ltd-and-Other---22072020.pdf,Protection,Breach of the Protection Obligation by MRI Diagnostics and Breach of the Accountability Obligation by Clarity Radiology,https://www.pdpc.gov.sg/all-commissions-decisions/2020/10/breach-of-the-protection-obligation-by-mri-diagnostics-and-breach-of-the-accountability-obligation-by-clarity-radiology,2020-10-16,"PERSONAL DATA PROTECTION COMMISSION
Case No. DP-1811-B2975
In the matter of an investigation under section 50(1) of the
Personal Data Protection Act 2012
And
(1) MRI Diagnostics Pte Ltd
(2) Clarity Radiology Pte Ltd

SUMMARY OF THE DECISION

MRI Diagnostics Pte Ltd (“NovenaMRI”) operates a medical centre that provides
magnetic resonance imaging and X-Ray services to patients. In the course of
their business, NovenaMRI subscribed to an internet based teleradiology system
(“System”) provided by Clarity Radiology Pte Ltd (“Clarity”). In-turn, Clarity
engaged an overseas IT vendor (the “IT Vendor”) to maintain the System.

On 7 November 2018, a patient of NovenaMRI (“Complainant”) notified the
Personal Data Protection Commission (the “Commission”) about an Excel
Spreadsheet containing approximately 600 individual’s personal data (including
the Complainant’s) that was accessible via the internet (the “Incident”).

During the course of investigations, the Commission found two additional Excel
Spreadsheets containing similar information as the Excel Spreadsheet reported
by the Complainant. A total of approximately 4,099 individuals were affected by
the Incident (“Affected Individuals”). The Affected Individuals’ personal data
that was exposed to unauthorised access included their names, NRIC numbers
and the type of radiology scans performed (collectively, the “Personal Data
Sets”).

The Commission’s investigations revealed that the Incident was caused by a
lapse in the IT Vendor’s processes while carrying out maintenance work on the
System. In particular, the IT Vendor had removed access restrictions to a
network folder containing the Excel Spreadsheets for the purposes of patching
the System, and omitted to reinstate the access restrictions after the patching
was completed. Without access restrictions, the Excel Spreadsheets (containing
the Personal Data Sets) were indexed by Google’s search engines and exposed
to unauthorised access.

NovenaMRI was an organisation who had collected the Personal Data Sets from
its patients, and had control of the Personal Data Sets at all material times.

Section 24 of the Personal Data Protection Act (“PDPA”) requires organisations
like NovenaMRI 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 or similar risks (the “Protection
Obligation”). In this regard, the Deputy Commissioner for Personal Data
Protection (“Deputy Commissioner”) finds NovenaMRI in breach of the
Protection Obligation because:
(a)

When an organisation engages a vendor to supply, modify and/or maintain
its IT system, it is required to provide the vendor with sufficient clarity and
specifications on the requirements to protect personal data. This is because
even if the vendor was not engaged to process personal data on the
organisation’s behalf, it may nevertheless handle the personal data
incidentally or make decisions that affect the security of the personal data
in the course of providing its services. Depending on the circumstances of
each case, the organisation should articulate its business requirements
concerning the protection of personal data that the IT system will store. This
will enable the vendor to assess and recommend the most appropriate and
effective method to protect personal data. The organization will then be able

to make a decision with access to the right information. Examples of
measures include having clauses in written agreements setting out clearly
the vendor’s obligations to protect personal data, providing operational
guidance and verifying the data protection arrangements implemented by
the vendor and/or exercising some form of supervision and oversight over
the vendor’s activities;

(b)

Given the nature of NovenaMRI’s business, which entailed being in
possession and/or control of personal data of a sensitive nature (e.g.
radiology scans and X-Rays), NovenaMRI should also have conducted a
proper assessment of its vendor to satisfy itself that the vendor is wellplaced to protect the personal data it hosts. For example, NovenaMRI could
have obtained documentary evidence that the vendor had complied with
industry standards with respect to information security (eg the ISO 27001
standard). However, in this case, there was no evidence that NovenaMRI
had conducted proper due diligence of the security standards put in place
by Clarity, prior to subscribing to the System that provided cloud-based
services, including hosting the Personal Data Sets;

(c)

Although NovenaMRI claimed that it had a written agreement with Clarity,
it was unable to produce supporting evidence of this. NovenaMRI’s claim
was also disputed by Clarity, who had admitted that there was no written
agreement between the parties. In addition, even after NovenaMRI had
engaged Clarity, NovenaMRI did not take any steps to verify if Clarity had
implemented any data protection arrangements with respect to the System
which hosted the Personal Data Sets.

As for Clarity, the contracted services from Clarity to NovenaMRI were to provide
an archive for Dicom Images and a Web-based radiology information system
with scheduling, registration, billing and client access modules. Essentially,
Clarity was a “Software as a Service” provider (or what is commonly known as

“SaaS-provider”) who had provided its cloud-based services to NovenaMRI. The
provision of such technical solutions or deployment of software integrated into
the clinical devices of NovenaMRI did not entail the processing of personal data.
As such, Clarity was a vendor of NovenaMRI, and not a “data intermediary” of
NovenaMRI. As a vendor, Clarity was not responsible for the protection of the
Personal Data Sets under the PDPA in respect of the Incident.

However, during the course of investigations, Clarity admitted that it had failed
to appoint a data protection officer and had not developed or put in place any
data protection policies, as required under Sections 11(3) and 12 of the PDPA.
Accordingly, Clarity is in breach of Sections 11(3) and 12 of the PDPA.

After considering the circumstances of the case, the Deputy Commissioner’s
decisions are as follows:

(a)

to issue a warning to NovenaMRI for its breach of the Protection Obligation.
No further directions are necessary as NovenaMRI has ceased its business
relationship with Clarity; and

(b)

to direct that Clarity shall, within 30 days from the date of this decision:
i.

Appoint a data protection officer;

ii.

Develop and implement a data protection policy to comply with its
obligations under the PDPA; and

iii.

Inform the Commission within 7 days of the completion of each of the
above directions.

",Warning,8906873bf2bf8d94f7c7b01b729303a770c83162
89,89,1,952,"A financial penalty of $9,000 was imposed on COURTS for failing to put in place reasonable security arrangements to protect the personal data of its members from unauthorised disclosure on its website. Some members were able to gain access to personal data of another member via a link in an email sent by COURTS.","[""Protection"", ""Financial Penalty"", ""Wholesale and Retail Trade"", ""Inadequate scoping of testing"", ""EDM"", ""Incorrect Setting""]",2020-10-16,https://www.pdpc.gov.sg/-/media/Files/PDPC/PDF-Files/Commissions-Decisions/Decision---COURTS-Singapore---140820.pdf,Protection,Breach of the Protection Obligation by COURTS,https://www.pdpc.gov.sg/all-commissions-decisions/2020/10/breach-of-the-protection-obligation-by-courts,2020-10-16,"PERSONAL DATA PROTECTION COMMISSION

[2020] SGPDPC 17
Case No DP-1909-B4731

In the matter of an investigation under section 50(1)
of the Personal Data Protection Act 2012
And
COURTS (Singapore) Pte Ltd.
… Organisation

DECISION

COURTS (Singapore) Pte Ltd
[2020] SGPDPC 17
Lew Chuen Hong, Commissioner — Case No DP-1909-B4731
14 August 2020

Introduction
1

On 6 September 2019, COURTS (Singapore) Pte Ltd (the

“Organisation”) notified the Personal Data Protection Commission (the
“Commission”) that an individual in its membership programme who had
received an Electronic Direct Mail (“eDM”) from the Organisation, was able to
access, without authentication, data in another individual’s account after
clicking on a link (the “New eDM Link”) in the eDM (the “Incident”).
Facts of the Case
2

The Organisation is a well-known consumer electronics and furniture

retailer, with a number of stores in Singapore. Its membership programme,
known as “homeclub by COURTS” (“Homeclub”) gives its members
(“Members”) exclusive access to, among other things, events and discounts.
The Organisation regularly sends eDMs to Members with links to specific
products on the Organisation’s website (the “Website”).

COURTS (Singapore) Pte Ltd

[2020] SGPDPC 17

The Organisation used a platform called Salesforce to create and send

eDMs (the “Platform”) and the Website ran on the Magento system1 (the
“System”), an e-commerce platform. The System generated a dynamic session
identifier (“SID”) for each login to Homeclub on the Website. This SID would
be used for all subsequent activities within the session.
4

On 31 August 2019, the Organisation sent an eDM to 76,844 Members

(the “Affected Members”). This eDM, included for the first time, the New
eDM Link, which was meant to direct Members to the Homeclub login page.
The purpose of the New eDM Link was for Members to log in to their respective
Homeclub accounts to update their membership identifier – Members were
required to provide their mobile numbers to replace NRIC numbers that were
previously used as the membership identifier.
5

The New eDM Link did not operate as intended, resulting in the

Incident. The Commission’s investigations revealed the following:
(a)

Notwithstanding that the eDM sent on 31 August 2019 included

for the first time the New eDM Link, the Organisation continued to use
the System in its default setting. The default setting comprised (i) the
SID embedded in the URL of the New eDM Link;2 and (ii) cookie
settings to be refreshed after 60 minutes.
(b)

The default setting had not caused any issues when it was used

by the Organisation to send marketing eDMs with eDM links directing
Members to specific products on the Website. As Members were not

The Organisation acquired a license to operate the System from 6 March 2017.

This was due to the default setting “Use SID on Storefront” being set to “Yes”

COURTS (Singapore) Pte Ltd

[2020] SGPDPC 17

required to log in to their accounts in order to view the specific products,
the SID embedded in the URL and cookie settings did not affect the
functioning of the Website.
(c)

However, the default setting should not have been used for the

New eDM Link – it led to the System assuming that every use of the
New eDM Link within 60 minutes of a Member’s login was part of the
same session. This meant that:
(i)

If Member X clicks on the New eDM Link and logs into

his Homeclub account without logging out within 60 minutes, all
other Members who subsequently clicked on the New eDM Link
within 60 minutes of Member X’s login would automatically be
directed to Member X’s account, without having to authenticate
their credentials; and
(ii)

If Member X logged out while other Members were still

logged into Member X’s account, the other Members would only
be logged out of Member X’s account if they refreshed a page or
navigated to other pages within Member X’s account.
6

According to the Organisation, 128 of the Affected Members clicked on

the New eDM Link between approximately 8am on 31 August 2019 and
12.25am on 1 September 2019.3 The Incident led to the risk of unauthorised
access and modification of personal data in the Affected Members’ respective
Homeclub accounts. In this regard, each Member’s Homeclub account

The eDM containing the New eDM Link was sent to Members at approximately 8am on 31
August 2019. The Organisation rectified the error causing the Incident at approximately
12.25am on 1 September 2019.

COURTS (Singapore) Pte Ltd

[2020] SGPDPC 17

comprised (i) account information; and (ii) address book, which collectively
contained the following data (“Personal Data Set”):
(a)

Name;

(b)

Email address:

(c)

Mobile Number;

(d)

Date of Birth (“DOB”);

(e)

Address;

(f)

Password; and

(g)

Transactional information i.e. products previously purchased by

a Member.
7

In addition to unauthorised access, the following types of personal data

in the Affected Members’ Personal Data Sets were at risk of unauthorised
modification as a result of the Incident:
(a)

The Affected Member’s name, DOB, mobile number and

residential address from his/her account information; and
(b)

The Affected Member’s name, mobile number and residential

address from his/her address book.
8

The risk of unauthorised modification in [7(a)] and [7(b)] was possible

because password verification was not required to make these changes.
Conversely, an Affected Members’ username (which was his/her email address)
and password could not be modified without password verification. An Affected
Member’s Personal Data Sets also could not be downloaded by another Member
4

COURTS (Singapore) Pte Ltd

[2020] SGPDPC 17

who had accessed his/her account because there was no download function on
the Website.
9

There was no risk of financial loss to Affected Members through the

Incident. While it was possible for another Member (who was given access to
Member X’s account) to make a purchase through Member X’s account, he/she
would have to provide credit card details to complete the purchase. This was
because financial information (i.e. credit card details) was not stored in the
System, and there was no reward system in Homeclub for the redemption of
products or benefits.
10

Based on the Organisation’s investigations into the Incident, there was

no evidence of any unauthorised modification to the Affected Members’
Personal Data Sets. Other than the Affected Member who had notified the
Organisation of the Incident, the Organisation did not receive any further
complaints or feedback.
11

Upon being notified of the Incident on the same day, the Organisation

promptly took the following remedial actions:
(a)

Fixed the error that caused the Incident at approximately

12:25am on 1 September 2019 by changing the setting for “Use SID on
Storefront” to “No”;
(b)

Implemented password verification for any changes to

Members’ account information and address book;4

This came into effect on 6 January 2020.

COURTS (Singapore) Pte Ltd

(c)

[2020] SGPDPC 17

Put in place a standard operating procedure (“SOP”) to ensure

correct link insertion into eDMs to protect personal data. For eDM links
that are supposed to lead to a login page, checks will be conducted to
ensure that there will be multiple concurrent user testing;
(d)

Took steps to engage an external vendor to work on security

matters (including data protection security), and disseminate this
information to its employees; and
(e)

Emailed the 128 Affected Members who had clicked on the New

eDM Link to inform them of the Incident.
The Commissioner’s Findings and Basis for Determination
Whether the Organisation had contravened section 24 of the PDPA
12

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”). It is not disputed that the Organisation had possession and control
of the Personal Data Sets at the material time. The Commission’s investigations
revealed that the Organisation failed to put in place reasonable security
arrangements to protect the Personal Data Sets for the reasons explained below.
13

First, the Organisation failed to conduct adequate testing before

implementation. As mentioned at [4], this was the first time the Organisation
included in its eDM, the New eDM Link to direct Members to the Homeclub
login page. There was only 1 employee in the Organisation’s digital marketing
team that was in charge of creating the New eDM Link and testing it prior to its

COURTS (Singapore) Pte Ltd

[2020] SGPDPC 17

launch. The employee conducted a limited test of sending the eDM containing
the New eDM Link to himself – the New eDM Link operated as intended,
directing the employee to the Homeclub login page. This limited test was clearly
inadequate. As emphasized in the Commission’s previous decisions, an
organisation should ensure that testing scenarios are properly scoped. In
particular, pre-launch testing of processes or systems needs to mimic expected
real world usage, including foreseeable scenarios in a normal operating
environment when the changes are introduced.5 In the present case, the
Organisation intended to send the eDM to a very large number of Members. It
is therefore foreseeable that testing scenarios should include multiple sequential
logins or even concurrent logins to the Homeclub login page at peak usage. If
the Organisation had tested the New eDM Link to approximate this real world
scenario, the Incident would have likely come to light at that stage.
14

Second, the Organisation failed to assess the appropriateness of the

default settings in the System for the New eDM Link.
(a)

The Organisation used the default setting in the System for the

New eDM Link without any assessment on its implications. As
mentioned in the Commission’s Guide to Securing Personal Data in
Electronic Medium at [17.5] and previous decisions,6 when using readymade software, organisations are required to obtain a clear
understanding of the intended purpose of the software, how the software

See Re Option Gift Pte Ltd [2019] SGPCPC 10 at [15]; Re AIA Singapore Pte Limited [2019]
SGPDPC 20 at [15] and L’Oreal Singapore Pte. Ltd. Case No. DP 1812-B3091, Summary of
the Decision at [3]
6

See for example Re DS Human Resource Pte Ltd [2019] SGPDPC 16 at [9]

COURTS (Singapore) Pte Ltd

[2020] SGPDPC 17

functions and how to configure the software correctly. The Organisation
failed to do so in the present case;
(b)

There was an option in the Platform to automatically generate

eDM links without any SID in the URL. The Organisation did not fully
appreciate the differences in using this option to create links that are
embedded within an eDM, as compared with the effects of embedding
SIDs as part of the URL for the New eDM Link. Due to the lack of
understanding the differences between these out-of-the-box features of
the commercial off-the-shelf product that he was using, the employee in
charge of creating the New eDM Link was not aware that the appropriate
method was to use the option in the Platform that generated eDM links
without SID in the URL. Instead, the employee manually copied the
New eDM Link (which contained the SID) from the internet browser for
insertion into the eDM; and
(c)

While the Organisation had in place a process for a second-level

check on the content and layout of the eDM, the nature of this type of
checks would not have been effective in picking up the more technical
issues relating to embedded SID in the New eDM Link. Understanding
fully the features of the commercial off-the-shelf product in use and
properly scoping the testing scenarios during user acceptance testing
would have been the more appropriate and effective way to avoid and
catch such errors.
15

For the reasons above, the Commissioner found the Organisation in

breach of section 24 of the PDPA.

COURTS (Singapore) Pte Ltd

[2020] SGPDPC 17

Representations by the Organisation
16

In the course of settling this decision, the Organisation made

representations on the amount of financial penalty that the Commissioner
intended to impose. The Organisation raised the following factors for the
Commissioner’s consideration:
(a)

The Organisation takes a serious view of its obligations under

the PDPA, and has taken the necessary remedial actions to prevent
future data protection incidents from occurring. Personal data protection
remains a priority for the Organisation even during these uncertain and
turbulent times amidst the COVID-19 pandemic; and
(b)

The COVID-19 pandemic has had an adverse impact on the

business of the Organisation, resulting in a significant loss of revenue.
Specifically, due to “circuit breaker” measures imposed by the
government, the Organisation closed all 14 of its retail outlets in
Singapore from 7 April 2020 to 19 June 2020. Further, its operating
overheads remained largely unchanged as labour accounted for
significant portion of its costs, and the Organisation has maintained a
commitment to retaining employees so as to protect their livelihoods.
Even with the recent reopening of its physical stores, the Organisation
continues to have a negative outlook of its business due to the impact of
COVID-19 on the economy and a challenging retail landscape.
17

Having carefully considered the representations, the Commissioner has

decided to reduce the financial penalty to the amount set out at [19]. The
quantum of financial penalty has been calibrated after due consideration of the
Organisation’s financial circumstances due to the unprecedented challenges
faced by businesses amid the current Covid-19 pandemic, bearing in mind that
9

COURTS (Singapore) Pte Ltd

[2020] SGPDPC 17

financial penalties imposed should not be crushing or cause undue hardship on
organisations. Although a lower financial penalty has been imposed in this case,
the quantum of financial penalty should be treated as exceptional and should not
be taken as setting any precedent for future cases.
The Commissioner’s Directions
18

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

under Section 29 of the PDPA, the Commissioner took into account as an
aggravating factor that this is the second time the Organisation has been found
in breach of the Protection Obligation.7 The Commissioner also took into
account the following mitigating factors:
(a)

The Organisation cooperated with the investigations and

provided prompt responses to the Commission’s requests for
information;
(b)

The Organisation implemented remedial actions swiftly to

address the Incident; and
(c)

The Members’ Personal Data Sets was exposed to the risk of

unauthorised access and/or modification for a limited period of less than
one day.
19

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

hereby directs the Organisation to pay a financial penalty of S$9,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

See Re Courts (Singapore) Pte Ltd [2019] SGPDPC 4

COURTS (Singapore) Pte Ltd

[2020] SGPDPC 17

on the outstanding amount of the financial penalty until it is paid in full. The
Commissioner has not set out any further directions given the remediation
measures already put in place.

YEONG ZEE KIN
DEPUTY COMMISSIONER
FOR COMMISSIONER FOR PERSONAL DATA PROTECTION

",Financial Penalty,7b84d1c0b092675d5ee94570a80a3de93072541d
90,90,1,952,A warning was issued to the Singapore Medical Association for failing to put in place reasonable security arrangements to prevent the unauthorised access of 68 individuals’ personal data which were forwarded to an external email address without authorisation.,"[""Protection"", ""Warning"", ""General (eg. Chamber of Commerce)"", ""Email forwarding"", ""Password policy""]",2020-09-10,https://www.pdpc.gov.sg/-/media/Files/PDPC/PDF-Files/Commissions-Decisions/Decision---Singapore-Medical-Association---21072020.pdf,Protection,Breach of the Protection Obligation by Singapore Medical Association,https://www.pdpc.gov.sg/all-commissions-decisions/2020/09/breach-of-the-protection-obligation-by-singapore-medical-association,2020-09-10,"PERSONAL DATA PROTECTION COMMISSION
Case No. DP-2001- B5770
In the matter of an investigation under section 50(1) of the
Personal Data Protection Act 2012
And
Singapore Medical Association

SUMMARY OF THE DECISION
1.

On 31 January 2020, Singapore Medical Association (the “Organisation”) notified the
Personal Data Protection Commission (the “Commission”) that the personal data of 68
individuals in 137 emails had been forwarded to an external email address without
authorisation between 28 and 30 January 2020. The personal data comprised National
Registration Identification Card numbers, dates of birth, indemnity coverage, period of
coverage, educational information and financial transaction information.

The Organisation believed an unauthorised user (“UU”) gained entry into the affected
Microsoft Office 365 email account by a brute force attack but did not have the system
logs to confirm this. Regardless, the unauthorised entry enabled the UU to create an email
rule to forward received emails to the external email address.

It was found that the Organisation failed to conduct periodic security reviews of its IT
system. Consequently, it missed the opportunity to detect the following security issues
that could have prevented the incident:

There was no periodic change to the passwords of email accounts. As an example,
the password to the affected account had not been changed since first use in
November 2013.

The Organisation collected financial information such as bank account details and
swift codes and should have considered, as part of a security review, whether it
needed to enhance security measures. For example, encryption of emails and/or
attachments containing such sensitive personal data.

A reasonable security review would also have noted the absence of security
arrangements against brute force attacks. Common examples of anti-brute force
measures include limiting the number of failed login attempts and account
lockouts. Without anti-brute force measures, a password-protected account could
be subjected to unlimited and uninterrupted automated login attempts from the
Internet. Given sufficient time, the attacker will succeed in arriving at the correct
password.

The Deputy Commissioner for Personal Data Protection therefore found that the
Organisation did not adopt reasonable steps to protect personal data in its possession or
under its control against risk of unauthorised access. The Organisation was in breach of
the Protection Obligation under section 24 of the Personal Data Protection Act 2012.
Upon consideration of the facts, a warning was issued to the Organisation. No directions
are required as the Organisation had taken actions to address the gaps in its security
arrangements.

",Warning,6c2d54a99a7623a26140ad101ee1ad4d4c2a792d
91,91,1,952,"A financial penalty of $20,000 was imposed on Civil Service Club for failing to put in place reasonable security arrangements to protect its members’ personal data. A web directory containing members’ profile photographs and their respective NRIC/FIN numbers was found to be publicly accessible.","[""Protection"", ""Financial Penalty"", ""Arts, Entertainment and Recreation"", ""Access control"", ""Public access""]",2020-09-10,https://www.pdpc.gov.sg/-/media/Files/PDPC/PDF-Files/Commissions-Decisions/Decision---Civil-Service-Club-01042020.pdf,Protection,Breach of the Protection Obligation by Civil Service Club,https://www.pdpc.gov.sg/all-commissions-decisions/2020/09/breach-of-the-protection-obligation-by-civil-service-club,2020-09-10,"PERSONAL DATA PROTECTION COMMISSION

[2020] SGPDPC 15
Case No DP-1907-B4180

In the matter of an investigation under section 50(1)
of the Personal Data Protection Act 2012
And
Civil Service Club
… Organisation

DECISION

Civil Service Club
[2020] SGPDPC 15
Tan Kiat How, Commissioner — Case No DP-1907-B4180
1 April 2020
Introduction
1

On 2 July 2019, the Personal Data Protection Commission (the

“Commission”) received a complaint from a member (the “Complainant”) of
the Civil Service Club (the “Organisation”). According to the Complainant,
when he accessed his virtual membership card (the “Virtual Card”) through
the

Organisation’s

membership

web

portal

the

same

day

–

“https://gateway.csc.sg” (the “Membership Portal”), he discovered that he was
able to access a web directory – “https://gateway.csc.sg/webclub/facilities/tmp”
(the “Directory”). The Directory contained profile photographs of other
members (and their respective NRIC/FIN numbers which were used as file
names for their profile photographs), including the Complainant’s (the
“Incident”).
Facts of the Case
2

The Organisation is a social club for all Public Service officers in

Singapore, and also welcomes staff of Social Service Organisations and the
general public to join as associate members. Membership benefits include
booking of sports facilities, functions rooms and chalets, as well as members’
rates for club events and recreational activities.

Civil Service Club

[2020] SGPDPC 15

In October 2009, the Organisation engaged the services of an IT vendor

(the “Vendor”) to develop its Club Management System (“CMS”). The
Vendor’s scope of work was set out in a contract entered into between the parties
in November 2009 (the “Contract”). The Organisation launched the CMS,
including the Membership Portal, in stages. On 1 March 2019, the Organisation
launched the Virtual Card on the Membership Portal, and members’ NRIC/FIN
numbers were used as file names for members’ profile photographs.
4

The Organisation has 2 separate servers hosted in its premises – the

“enterprise” server (the “Enterprise Server”) and the “gateway” server (the
“Gateway Server”). The Organisation stored its business and personal data on
the Enterprise Server. The Gateway Server was specifically deployed to isolate
the rest of the Organisation’s network (which may contain personal data or
business data) from the public.
5

When a member accessed his/her Virtual Card, the software on the

Membership Portal retrieved a copy of the member’s profile photograph from
the Enterprise Server and stored it temporarily in the Directory. The Directory
resided in the Gateway Server. The files in the Directory (including members’
profile photographs) were designed such that they could not be accessed by the
public. If the member logged out from the Membership Portal, his/her profile
photograph would be deleted from the Directory at that point in time. However,
if the member closed the web browser directly without logging out of the
Membership Portal, his/her profile photograph in the Directory would only be
deleted during the monthly “housekeeping” process. Other than members’
profile photographs stored temporarily in the Directory (and their respective
NRIC/FIN numbers which were used as file names for their profile
photographs), the Gateway Server did not contain any other personal data.

Civil Service Club

[2020] SGPDPC 15

Prior to the Incident, there was an issue arising from members

submitting their profile photographs in different file formats and sizes for the
Virtual Card. The Vendor planned to monitor the situation for three months until
9 July 2019 and troubleshoot the issue during this period.
7

At first, the Vendor attempted to perform troubleshooting in a test

environment using dummy photographs. However, the test environment could
not replicate the issue with the Virtual Cards. In order to observe members’
behaviour patterns when they accessed their Virtual Cards and to collect
statistics on photograph file sizes and time of creation, the Vendor enabled
public access to the Directory on 3 occasions so that it could perform
troubleshooting remotely. The Vendor also postponed the monthly
“housekeeping"" process for the Directory by pushing it back from June 2019 to
July 2019.
8

The Vendor only required a few minutes of remote access to perform

remote troubleshooting, and had, as part of its testing procedures, a requirement
that engineers restore all changes made during testing. On the first 2 occasions,
public access to the Directory was disabled within 15 minutes. However, on 24
June 2019 (i.e. the 3rd occasion of remote troubleshooting), the Vendor’s
engineer omitted to disable public access to the Directory but erroneously
reported that he had done so. As a result, approximately 1,770 members’ profile
photographs (and their respective NRIC/FIN numbers which were used as file
names for their profile photographs) (the “Members Data”) could be accessed
by anyone who obtained the URL to the Directory, including the Complainant
on the date of the Incident.
9

Upon being notified of the Incident, the following remedial actions were

taken:

Civil Service Club

(a)

[2020] SGPDPC 15

The Organisation and the Vendor took immediate action to

disable access to the Directory;
(b)

The Vendor enhanced the “housekeeping” processes for the

Directory such that the members’ profile photographs are deleted
immediately after displaying them on the respective members’ Virtual
Cards (i.e. there are no files containing members’ profile photographs
stored in the Directory at any time); and
(c)

The Organisation discontinued the use of NRIC/FIN numbers as

membership numbers, and the members’ profile photographs are no
longer named using NRIC/FIN numbers.
The Commissioner’s Findings and Basis for Determination
Whether the Organisation had contravened section 24 of the PDPA
10

As a preliminary point, the Organisation owned the Enterprise Server

and Gateway Server, and was in possession and control of the Members Data at
all material times. While the Organisation had engaged the Vendor to develop
the CMS, which included the Membership Portal, the scope of the Vendor’s
work did not involve processing of any personal data on behalf of the
Organisation. The Vendor was therefore not a data intermediary, and the
responsibility to protect the Members Data fell squarely on the Organisation.
11

Section 24 of the Personal Data Protection Act 2012 (“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”). The Organisation failed to put in place reasonable

Civil Service Club

[2020] SGPDPC 15

security arrangements to protect the Members Data for the reasons explained
below.
12

As mentioned at [3], the Organisation started engaging the Vendor’s

services in October 2009. The Contract between the parties was entered into
before the PDPA came into full force on 2 July 2014 (the “Appointed Day”).
Before the Appointed Day, the Data Protection Provisions of the PDPA (i.e.
Parts III to VI of the PDPA) were not in force, and the Organisation was not
subject to these provisions in relation to personal data in its possession or
control. However, after the Appointed Day, it became incumbent on the
Organisation to take proactive steps to comply with the Data Protection
Provisions of the PDPA in respect of the existing personal data held in its
possession or control, as well as any new personal data that may come into its
possession or control. It was not enough for the Organisation to leave matters
status quo, if this would not enable it to meet the requirements and standards of
the Protection Obligation.1
13

In the present case, the Commission’s investigations revealed that after

the Appointed Day, the Organisation’s engagement of the Vendor’s services
included work in relation to the developing and troubleshooting of the Virtual
Cards on the Membership Portal. According to the Organisation, it was not
aware that (i) Members Data had been stored temporarily in the Directory; and
(ii) the Vendor’s troubleshooting involved enabling public access to the
Directory. Notwithstanding this, given that the Organisation’s engagement of
the Vendor’s services included work in relation to the Virtual Cards that
contained Members Data, the Vendor (although not engaged to process the

See Re Social Metric Pte Ltd [2017] SGPDPC 17 at [10] – [11]

Civil Service Club

[2020] SGPDPC 15

Members Data) may nevertheless handle the Members Data incidentally or
make software system design decisions that affect the security of the Members
Data in the course of providing its services.
14

In the circumstances, and in order for the Organisation to comply with

the Protection Obligation, the Organisation should have ensured that it provided
sufficient clarity and specifications on requirements to the Vendor (when
developing and troubleshooting the CMS, Membership Portal and Virtual
Cards) to protect the Members Data. There are various ways that the
Organisation could have done so:
(a)

The Contract was entered into by the parties before the

Appointed Day and did not contain any provisions on the protection of
personal data.2 In view of the scope of services provided by the Vendor
after the Appointed Day as set out at [13], the Organisation could have
reviewed the Contract to include clauses setting out requirements for the
Vendor to protect the Members Data. As highlighted in the
Commission’s Guide on Building Websites for SMEs (revised 10 July
2018) at [4.2.1], organisations should emphasize the need for personal
data protection to their IT vendors by making it part of their contractual
terms. In this regard, the Organisation could have adapted relevant
clauses from the Commission’s Guide on Data Protection Clauses for
Agreements Relating to the Processing of Personal Data (published 20
July 2016) to suit the Organisation’s particular circumstances and needs.

The Contract contained only a confidentiality clause requiring each party to protect
information identified by the other party as confidential.

Civil Service Club

(b)

[2020] SGPDPC 15

Further and/or in the alternative, the Organisation could have

reviewed and revised the requirements specifications and software
systems design documentation to include (i) requirements relating to
how personal data (including the Members Data) should be handled as
part of the design and layout the CMS and the Membership Portal;3 and
(ii) technical and other measures that protect the personal data (including
the Members Data).
15

From the Appointed Day, the Organisation’s failure to take any

reasonable steps to ensure sufficient obligations are imposed on the Vendor
(when developing and troubleshooting the CMS, Membership Portal and
Virtual Cards) to protect the Members Data was a breach of its obligations under
section 24 of the PDPA. A period of about five years had elapsed since 2 July
2014 to 2 July 2019. The Organisation, as owner of the CMS, should have
included it as part of its personal data asset inventory and ensured that its data
protection policies covered personal data held in the CMS. Had this been done,
the Organisation would have identified these gaps in the business requirements
for the CMS, which would have set it down the path to rectifying these gaps
through one or both of the options discussed in the preceding paragraph. The
Organisation, as owner of the CMS, is responsible for identifying the omission
and articulating its business requirements relating to the protection of personal
data stored in the CMS. This would have led to action by the Vendor in
recommending technical fixes to enhance the CMS. It is the failure to identify
the omission and articulate business requirements, and for a not-trivial period
of five years, that is the gravamen of the Organisation’s breach of the PDPA.

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

Civil Service Club

[2020] SGPDPC 15

The Commissioner’s Directions
16

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 cooperated with investigations;

(b)

There was limited risk to the Members Data arising from the

Incident because (i) there was only one complaint received; and (ii) even
if the Incident had not occurred, the Directory’s exposure to public
access would have been discovered and rectified by 9 July 2019 because
the Organisation and Vendor had planned to carry out a security audit
on that date; and
(c)

The Organisation took prompt remedial action to rectify the

Incident.
17

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

directs the Organisation to pay a financial penalty of S$20,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 the financial penalty until it is paid in full. The
Commissioner has not set out any further directions given the remediation
measures already put in place.

YEONG ZEE KIN
DEPUTY COMMISSIONER
FOR COMMISSIONER FOR PERSONAL DATA PROTECTION

",Financial Penalty,f0321512ea7fdd1c3b0f5d62f673deb9411f9019
92,92,1,952,"A financial penalty of $10,000 was imposed and a direction was issued to Grabcar for failing to put in place reasonable security arrangements to prevent the unauthorised access of GrabHitch drivers’ and passengers’ personal data via its mobile application.","[""Protection"", ""Financial Penalty"", ""Directions"", ""Transport and Storage"", ""Mobile application"", ""Code review""]",2020-09-10,https://www.pdpc.gov.sg/-/media/Files/PDPC/PDF-Files/Commissions-Decisions/Decision---Grabcar-Pte-Ltd---24072020.pdf,Protection,Breach of the Protection Obligation by Grabcar,https://www.pdpc.gov.sg/all-commissions-decisions/2020/09/breach-of-the-protection-obligation-by-grabcar,2020-09-10,"PERSONAL DATA PROTECTION COMMISSION

[2020] SGPDPC 14

Case No. DP-1909-B4675

In the matter of an investigation under section 50(1)
of the Personal Data Protection Act 2012
And
Grabcar Pte Ltd
… Organisation

DECISION

Grabcar Pte Ltd
[2020] SGPDPC 14

Yeong Zee Kin, Deputy Commissioner — Case No. DP-1909-B4675
21 July 2020

Introduction
1

Grabcar Pte Ltd (the “Organisation”) is a Singapore-based company

offering ride-hailing transport services, food delivery and digital payment
solutions through its mobile application (the “Grab App”). The Grab App also
provides a carpooling option referred to as “GrabHitch”. GrabHitch matches a
passenger with a driver willing to give a lift to the passenger (on the way to the
driver’s destination) in return for a fee. On 30 August 2019, the Organisation
notified the Personal Data Protection Commission (the “Commission”) that, for
a short period of time on the same day, profile data of 5,651 GrabHitch drivers
was exposed to the risk of unauthorised access by other GrabHitch drivers
through the Grab App (the “Incident”).
Facts of the Case
2

The Organisation’s investigations traced the cause of the Incident to the

deployment of an update to the Grab App on 30 August 2019 (the “ Update”).
The purpose of the Update was to address a potential vulnerability discovered
within the Grab App, namely, the application programming interface (“API”)
endpoint (/users/{userID}/profile) (the “URL”) that had allowed GrabHitch

Grabcar Pte Ltd

[2020] SGPDPC 14

drivers to access their data, contained a ‘userID’ that could potentially be
manipulated to allow access to other GrabHitch driver’s data.1
3

In order to fix the vulnerability, the Update removed the variable

‘userID’ from the URL which shortened it to a hard-coded ‘/users/profile’.
However, the Update failed to take into account the URL-based caching
mechanism in the Grab App. This caching mechanism (which was configured
to refresh every 10 seconds) served cached content in response to data requests
to reduce the load of direct access to the Organisation’s database.
4

With the deployment of the Update, all URLs in the Grab App ended

with “/users/profile”. Without the variable ‘userID’ in the URL (which directed
data requests to the correct GrabHitch driver’s accounts), the caching
mechanism could no longer differentiate between GrabHitch drivers.
Consequentially, the caching mechanism provided the same data to all
GrabHitch drivers for 10 seconds before new data was retrieved from the
Organisation’s database and cached for the next 10 seconds.
5

As a result of the Incident, a total of 21,541 GrabHitch drivers’ and

passengers data was exposed to the risk of unauthorised access (collectively
“Personal Data Sets”):
(a)

Profile pictures;

(b)

Passenger names;

(c)

Vehicle plate number; and

According to the Organisation, there was no evidence that this vulnerability had been
exploited.

Grabcar Pte Ltd

(d)
6

[2020] SGPDPC 14

Wallet balance comprising journal history of ride payments.

In addition to the Personal Data Sets, other data that was exposed to the

risk of unauthorised access during the Incident included GrabHitch booking
details such as addresses and pickup and drop-off times; and driver details such
as total rides, vehicle model and make.
7

Upon being notified of the Incident, the Organisation took the following

remedial actions:
(a)

Rolled back the Grab App to the version prior to the Update

within approximately 40 minutes;
(b)

Notified 5,651 GrabHitch drivers of the Incident on the same

day; 2
(c)

Increased the minimum “cash out” amount for wallets in

GrabHitch to S$200,000 to prevent unauthorised transfers;
(d)

Deployed a new update for the Grab App on 10 September 2019;

(e)

Reviewed its testing procedures including implementing

mandatory automated tests for all API endpoints dealing with personal
data;
(f)

Updated governance procedures concerning deployment and

security verification on changes to IT systems and applications; and

2 The Organisation’s initial investigations indicated

that 5,651 GrabHitch drivers’ data was
exposed to the risk of unauthorised access due to the Incident. Following further investigations,
the Organisation determined that up to 21,541 GrabHitch drivers’ and passengers data was
exposed to the risk of unauthorised access.

Grabcar Pte Ltd

(g)

[2020] SGPDPC 14

Embarked on an architecture review of its legacy applications,

and relevant codes which had not been reviewed for an extended period
of time.
The Commissioner’s Findings and Basis for Determination
Whether the Organisation had contravened section 24 of the PDPA
8

Section 24 of the Personal Data Protection Act 2012 (“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. It is
not disputed that the Organisation had possession and control of the Personal
Data Sets at the material time.
9

In the context of the present case, given that the Organisation made

changes to its IT system that processed the Personal Data Sets, it is obliged to
put in place reasonable security arrangements to prevent any compromise to the
Personal Data Sets.3 The Organisation failed to do so for the reasons explained
below.
10

First, the Organisation did not put in place sufficiently robust processes

to manage changes to its IT system that may put the personal data it was
processing at risk. This was a particularly grave error given that this is the

3 Re Flight Raja Travels Singapore Pte Ltd [2018] SGPDPC 16 at [8].

Grabcar Pte Ltd

[2020] SGPDPC 14

second time the Organisation is making a similar mistake, albeit with respect to
a different system.4
(a)

The Organisation introduced changes to the Grab App (through

the Update) without understanding how the changes would operate with
existing features of the Grab App and its broader IT system, including
the caching mechanism.
(b)

In particular, the Update involved changes to the URL (i.e.

removing the variable ‘userID’). The variable ‘userID’ in the URL had
the function of ensuring that data requests (including the Personal Data
Sets) were directed to the correct GrabHitch drivers’ accounts. However,
the Organisation implemented the Update without making an
assessment whether the Grab App would continue to direct data requests
to the correct GrabHitch drivers’ accounts without the variable ‘userID’
in the URL.
11

Second, the Organisation did not conduct properly scoped testing before

the Update to the Grab App was deployed.
(a)

As found in the Commission’s previous decisions, organisations

are obliged to conduct properly scoped testing before new IT features or
changes to IT systems are deployed. These tests need to mimic real
world usage, including foreseeable scenarios in a normal operating

4 See Re Grabcar Pte Ltd [2019] SGPDPC 15 at [17] where it was found that the Organisation

did not have adequate measures in place to detect whether the changes it made to a system that
held personal data introduced errors that put the personal data it was processing at risk.

Grabcar Pte Ltd

[2020] SGPDPC 14

environment when the changes are introduced.5 Such tests prior to
deployment are critical to enable organisations to detect and rectify
errors in the new IT features and/or be alerted to any unintended effects
from changes that may put personal data at risk.6
(b)

In the present case, the Organisation admitted that it did not

conduct tests to simulate multiple users accessing the Grab App, whether
concurrently or consecutively. The Organisation also admitted that it did
not conduct any specific test to verify how the caching mechanism
would work in tandem with the Update.
(c)

In view of the large number of GrabHitch drivers, multiple users

logging in concurrently or consecutively are foreseeable scenarios that
the Organisation should have simulated during its testing of the Update
prior to deployment. Properly scoped pre-launch tests would have
included an assessment of how the caching mechanism may affect the
intended operation of the Update because the caching mechanism can
affect data requests returned to the GrabHitch drivers.
12

For the reasons above, I find the Organisation in breach of section 24 of

the PDPA.

5 Re AIA Singapore Pte Limited [2019] SGPDPC 20 at [15] and L’Oreal Singapore Pte. Ltd.

Case No. DP 1812-B3091, Summary of the Decision at [3].
6 See for

example Re Flight Raja Travels Singapore Pte Ltd [2018] SGPDPC 16 and Re
Singapore Telecommunications Limited [2019] SGPDPC 36.

Grabcar Pte Ltd

[2020] SGPDPC 14

The Deputy Commissioner’s Directions
13

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

under Section 29 of the PDPA, I took into account as a mitigating factor that the
Organisation cooperated with the investigation, and was prompt and
forthcoming in its response to queries during the Commission’s investigations.
I have also taken into consideration that this is the fourth time the Organisation
has been found in breach of Section 24 of the PDPA. 7 Given that the
Organisation’s business involves processing large volumes of personal data on
a daily basis, this is a significant cause for concern.
14

Having considered all the relevant factors of this case, I direct the

Organisation to pay a financial penalty of S$10,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 the financial penalty until it is paid in full. In order to
reduce the risk of another data breach, I also direct the Organisation to put in
place a data protection by design policy for its mobile applications within 120
days of the date of this direction.

YEONG ZEE KIN
DEPUTY COMMISSIONER
FOR PERSONAL DATA PROTECTION

7 The previous decisions being Re Grabcar Pte Ltd [2018] SGPDPC 23; Re Grabcar Pte Ltd

[2019] SGPDPC 14; and Re Grabcar Pte Ltd [2019] SGPDPC 15.

","Financial Penalty, Directions",eb17aef1e75850888d8ec821aa37aebe142109b2
93,93,1,952,Singtel was found not in breach for failing to make reasonable security arrangements to prevent the unauthorised access of its customers’ personal data via the mySingtel mobile application.,"[""Not in Breach"", ""Others"", ""No breach"", ""Mobile application"", ""Singtel""]",2020-09-10,https://www.pdpc.gov.sg/-/media/Files/PDPC/PDF-Files/Commissions-Decisions/Decision---Singapore-Telecommunications-Limited---05082020.pdf,,No Breach of the Protection Obligation by Singtel,https://www.pdpc.gov.sg/all-commissions-decisions/2020/09/no-breach-of-the-protection-obligation-by-singtel,2020-09-10,"PERSONAL DATA PROTECTION COMMISSION

[2020] SGPDPC 13
Case No. DP-1904-B3731

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

And

Singapore Telecommunications Limited
… Organisation

DECISION

Singapore Telecommunications Limited
[2020] SGPDPC 13

Yeong Zee Kin, Deputy Commissioner — Case No. DP-1904-B3731
5 August 2020

Introduction
1

On 28 March 2019, Singapore Telecommunications Limited (the

“Organisation”) was notified by a customer of an issue with its MySingtel
mobile application (the “Mobile App”) – customers were able to view on the
Mobile App their previously assigned service numbers 1 (the “Recycled
Numbers”) and the related usage information of other customers who were the
current users of the Recycled Numbers (the “Incident”). The Organisation
notified the Personal Data Protection Commission (the “Commission”) of the
Incident on 17 April 2019.
Facts of the Case
2

The Organisation is a multinational telecommunications conglomerate

headquartered in Singapore. Through the Mobile App, the Organisation’s
customers can conveniently manage the Organisation’s services including (but

service numbers comprised mobile phone numbers, user IDs for the Organisation’s
broadband internet services and service numbers for the Organisation’s TV services.
1 The

Singapore Telecommunications Limited

[2020] SGPDPC 13

not limited to) the payment of their bills, keeping track of their local mobile data
usage, talk time and SMS, subscribing to a roaming plan to suit their travel needs
etc. Communications between the Mobile App and the Organisation’s servers
are conducted via an Application Programming Interface (“API”). This would
include the retrieval of active service numbers associated with a user of the
Mobile App.
3

The Organisation engaged a software services provider who was in

charge of developing and introducing code changes for the purpose of code
updates to the API (the “Vendor”). As part of a scheduled code update on the
day of the Incident, the Vendor made changes to the API code. In addition, the
Vendor also conducted code optimisation by running a tool called SonarQube,
which identifies and recommends inefficient code for removal. On this
particular occasion, SonarQube recommended the removal of the code which
governed the condition that decoupled Recycled Numbers from their previous
users (the “Condition”). The Vendor followed SonarQube’s recommendation
and removed the Condition.
4

Before the code changes were deployed to production, the Vendor raised

a Technical Change Request form (“TCR”) to notify the Organisation of the
changes made. However, the Vendor omitted to report the removal of the
Condition in the TCR submitted to the Organisation.
5

Prior to accepting the code changes to the API for deployment, the

Organisation conducted business user acceptance testing for business needs and
regression testing for existing functionality. Given that this was a scheduled
code update, these tests were limited in scope to the changes reported in the
TCR. As the removal of the Condition was not reported in the TCR, the
Organisation was unaware of this change, and did not conduct testing on the

Singapore Telecommunications Limited

[2020] SGPDPC 13

impact to the operation of the Mobile App due to removal of the Condition.
Following the pre-launch testing, the code changes were approved by the
Organisation for deployment.
6

The removal of the Condition led to the API retrieving both active and

Recycled Numbers associated with a user of the Mobile App, resulting in the
Incident. According to the Organisation, 384 of its customers were affected by
the Incident (the “Affected Individuals”). The following types of personal data
of the Affected Individuals’ that was at risk of unauthorised access through the
Mobile App included (collectively, the “Personal Data Sets”):
(a)

Recycled Numbers2;

(b)

Installation addresses of those Affected Individuals who

subscribed to the Organisation’s broadband and TV services;
(c)

Usage details including mobile phone talk time, number of text

messages sent and amount of mobile data used;
(d)

Value-added services subscribed to;

(e)

Price plans of the various services subscribed to; and

(f)

Billing cycles for the Recycled Numbers.

2 There was a total of 404 unique Recycled Numbers belonging to the Affected Individuals.

Singapore Telecommunications Limited

[2020] SGPDPC 13

Upon being notified of the Incident, the Organisation promptly carried

out the following actions to mitigate the effects of the Incident:
(a)

Blocked access to the Mobile App a few hours after being

notified of the Incident;
(b)

Implemented a fix for the Mobile App the day after the Incident,

and restored access to the Mobile App; and
(c)

Reversed five erroneous transactions relating to roaming and

callerID that were processed during the Incident.
8

In addition, to prevent a recurrence of the Incident or similar risks:
(a)

The Organisation will be implementing additional regression test

scenarios which will cover testing of Recycled Numbers;
(b)

The Organisation has also implemented the following

enhancements on the Mobile App:
(i)

To prevent any historical services from being retrieved

and displayed on the Mobile App, only active services will be
displayed moving forward; and
(ii)

Enhanced the Mobile App to ensure that only

information retrieved for the customer’s identifiers in the
authenticated session is displayed on the Mobile App.
Findings and Basis for Determination
9

As a preliminary point, the Organisation owned the Mobile App and was

in possession and control of the Personal Data Sets. The Vendor’s role, in the
context of the Incident, was to develop and introduce code changes to the API
4

Singapore Telecommunications Limited

[2020] SGPDPC 13

for the purposes of the code update. The Vendor did not process the Personal
Data Sets on behalf of the organisation and was accordingly not a data
intermediary. In the circumstances, the responsibility to protect the Personal
Data Sets fell squarely on the Organisation.
10

Section 24 of the Personal Data Protection Act 2012 (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”).
11

As highlighted in previous decisions 3, an organisation is not required to

provide an absolute guarantee for the protection of personal data in its
possession. What is expected of the organisation is to make such security
arrangements as a reasonable person would consider appropriate, given the
nature of the personal data involved and the particular circumstances of the
Organisation. The Protection Obligation is not automatically breached upon the
occurrence of a data leak, and this case is an example of an application of this
principle.
12

The

Commission’s

investigations

revealed

that

the

security

arrangements put in place by the Organisation to protect the Personal Data Sets
was reasonable in the circumstances for the reasons explained below.

3Re Tiger Airways Singapore Pte Ltd [2017] SGPDPC 6 and Re BHG (Singapore) Pte Ltd

[2017] SGPDPC 16.

Singapore Telecommunications Limited

(a)

[2020] SGPDPC 13

First, the Organisation emphasized to the Vendor the need for

personal data protection of the Organisation’s customers by making it
part of the contractual terms in the Statement of Works 4. Specifically,
the Statement of Works contained data protection clauses requiring the
Vendor to establish security processes and actively enforce policies
addressing personal data protection, follow industry standard measures
to protect the Organisation’s customers’ personal data, and exercise the
same degree of care to guard against unauthorised disclosure. In
addition, the Organisation verified the data protection arrangements put
in place by the Vendor to protect its customers’ data5. This included
conducting audits on the Vendor to ensure the adequacy and
effectiveness of IT controls and processes implemented by the Vendor,
and to ensure that the Vendor’s staff conformed to the said IT controls
and processes. Further, in order to increase its vendors’ knowledge and
awareness of the PDPA’s requirements, the Organisation also conducted
mandatory annual briefings for its vendors on the PDPA, the
Organisation’s cybersecurity policy for third party vendors as well as
information security. These annual briefings were attended by the
Vendor’s employees.

4 Commission’s Guide on Building Websites for SMEs (revised 10 July 2018) at [4.2.1].
5cf. Re SCAL Academy Pte Ltd [2020] SGPDPC 2 at [8]: Organisation instructed its vendor to

prevent documents from being “leaked” online, but did not check with its vendor what security
arrangements were put in place to ensure this.

Singapore Telecommunications Limited

(b)

[2020] SGPDPC 13

Second, the Organisation ensured that the pre-launch tests for

code changes were reasonably scoped to pick up and rectify errors
and/or flaws prior to deployment.
(i)

The

Organisation

had

conducted

business

user

acceptance testing based on the change requests set out by the
Vendor in the TCR. As mentioned at [5], there was no testing
conducted on the impact to the operation of the Mobile App due
to removal of the Condition – the Organisation was not aware of
the removal of the Condition because it had not been reported in
the TCR. Given that there was no reason for the Organisation to
suspect any additional code changes in a scheduled routine code
update, it was reasonable for the Organisation to perform testing
only on those changes set out in the TCR 6.
(ii)

As part of its quality assurance measures, the

Organisation conducted various testing of critical business
functions of the Mobile App, including user acceptance testing
and regression testing. The results from the tests were reviewed
by directors in the Organisation’s business and IT departments
before the code changes were approved for deployment to the
Mobile App.

6cf: The Commission’s previous decisions where organisations were found in breach of Section

24 of the PDPA for not conducting sufficiently scoped pre-launch tests before introducing new
changes to its systems that processed personal data. See for example: Re Flight Raja Travels
Singapore Pte Ltd [2018] SGPDPC 18 (organisation introduced a new mobile application) and
Re Singapore Telecommunications Limited [2019] SGPDPC 49 (organisation migrated its
database of customer accounts to a new billing system).

Singapore Telecommunications Limited

[2020] SGPDPC 13

In conclusion, nothing in the Commission’s investigations pointed to the

cause of the Incident being due to a systemic problem in the Organisation’s
measures to protect the Personal Data Sets. Instead, this appeared to be a oneoff incident that was difficult to foresee in the circumstances. Having carefully
considered all the relevant circumstances and for the reasons set out above, I
find that the Organisation had not contravened its obligations under section 24
of the PDPA.

YEONG ZEE KIN
DEPUTY COMMISSIONER
FOR PERSONAL DATA PROTECTION

",Not in Breach,cf1510a1a435f6eb0468b1dd403f3cf6c72407a6
94,94,1,952,"A financial penalty of $5,000 was imposed on Singapore Red Cross for breaches of the PDPA. First, the Organisation failed to put in place reasonable security arrangements to protect the personal data of its blood donors. Second, it was also found to be retaining personal data which was no longer necessary for legal or business purposes.","[""Protection"", ""Financial Penalty"", ""Social Service"", ""Security"", ""Retention""]",2020-09-10,https://www.pdpc.gov.sg/-/media/Files/PDPC/PDF-Files/Commissions-Decisions/Decision---Singapore-Red-Cross---05052020.pdf,Protection,Breach of the Protection and Retention Limitation Obligations by Singapore Red Cross,https://www.pdpc.gov.sg/all-commissions-decisions/2020/09/breach-of-the-protection-and-retention-limitation-obligations-by-singapore-red-cross,2020-09-10,"PERSONAL DATA PROTECTION COMMISSION

[2020] SGPDPC 16
Case No DP-1905-B3865

In the matter of an investigation under section 50(1)
of the Personal Data Protection Act 2012
And
Singapore Red Cross Society
… Organisation

DECISION

Singapore Red Cross Society

[2020] SGPDPC 16

Singapore Red Cross Society
[2020] SGPDPC 16
Tan Kiat How, Commissioner — Case No DP-1905-B3865
5 May 2020
Facts of the Case
1

Singapore Red Cross Society (the “Organisation”) operates a website at

http://www.redcross.sg (the “Website”) which allows the public to make appointments for
blood donations. For this purpose, the Organisation collects personal data of individuals such
as their names, contact numbers, email addresses and blood types (the “Personal Data”). The
Personal Data was stored in the Organisation’s blood donor appointment database (the
“Database”) accessible via the Website.
2

On 9 May 2019, the Organisation notified the Personal Data Protection Commission

(the “Commission”) that unauthorised individual(s) accessed and ex-filtrated the Personal
Data of approximately 4,297 individuals (“Affected Individuals”) from the Database (the
“Incident”).
3

Upon being notified of the Incident, the Organisation took the following remedial

actions:
(a)

Removed the appointment booking system on its Website in order to

temporarily cease its collection of Personal Data through that channel; and
(b)

Revised and strengthened its internal procedures to comply with the PDPA.

Singapore Red Cross Society

[2020] SGPDPC 16

The Commissioner’s Findings and Basis for Determination
The Organisation admitted that it had contravened Section 24 of the PDPA
4

Section 24 of the Personal Data Protection Act 2012 (“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”).
5

The Organisation admitted that it failed to implement adequate security measures to

protect the Personal Data stored in the Database, and had breached the Protection Obligation.
In particular, the Organisation admitted to the following specific mistakes:
(a)

The Organisation employed a vendor to develop the Website. However, there

was a lack of supervision over the vendor’s work which led to a failure to detect the
presence of a phpMyAdmin database administration tool (the “Tool”) which was used
to manage the Database. There was also no password management policy requiring
strong passwords of sufficient length and complexity during the development phase.
This resulted in a weak password (i.e. “12345”) being set for the Tool;1 and
(b)

The Organisation did not conduct any regular security reviews, e.g.

vulnerability assessment, on its systems that would identify applications that it did not
need. 2 Consequentially, the Organisation did not realise that the Tool remained
connected to the Website even after development of the Website had been completed.
This allowed unauthorised individual(s) to gain access to the Database through the Tool
which had a weak password.

For examples of the Commission’s previous decisions on the need for proper password management policies,
see Re Orchard Turn Developments Pte Ltd [2017] SGPDPC 12 at [35] – [36] and Re Spize Concepts Pte Ltd
[2019] SGPDPC 22 at [15].
2
For examples of the Commission’s previous decisions on the requirement for periodic security reviews, see
Re Watami Food Services Singapore Pte Ltd [2018] SGPDPC 12 at [6]; Re WTS Automotive Services [2018]
SGPDPC 26 at [18]; Re Bud Cosmetics [2019] SGPDPC 1 at [24]; Re Chizzle Pte Ltd [2019] SGPDPC 44 at [6].

Singapore Red Cross Society

[2020] SGPDPC 16

The Organisation admitted that it had contravened Section 25 of the PDPA
6

Under Section 25 of the PDPA, an organisation is obliged to cease to retain its

documents containing personal data, or remove the means by which the personal data can be
associated with particular individuals, as soon as it is reasonable to assume that: (a) the purpose
for which the personal data was collected is no longer served by retaining the data; and (b) the
retention is no longer necessary for legal or business purposes (the “Retention Limitation
Obligation”).
7

The Organisation admitted that there had been unnecessary retention of Personal Data

of approximately 900 Affected Individuals, and this was a breach of the Retention Limitation
Obligation.
(a)

Prior to the Incident, the Organisation intended to purge Personal Data of these

900 Affected Individuals from the Database. However, the Organisation provided
wrong instructions to its vendor for the purging exercise. The Organisation had
instructed its vendor to only remove some data elements instead of entire records of the
900 Affected Individuals’ Personal Data; and
(b)

The Organisation also did not conduct any verification checks to ensure the

purging exercise was properly carried out. As a result, the Organisation failed to detect
that the Database still retained records of the 900 Affected Individual’s Personal Data.
8

In view of the above, the Commissioner found the Organisation in breach of sections

24 and 25 of the PDPA.
The Organisation’s Representations
9

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

amount of financial penalty that the Commissioner intended to impose. The Organisation raised
the following factors for the Commissioner’s consideration:

Singapore Red Cross Society

(a)

[2020] SGPDPC 16

The Organisation is a charity that depends on public donations to run its

operations and programmes, all which are for the benefit of the community. Such a high
financial penalty would set the Organisation back significantly, and would mean less
help for the disadvantaged and the vulnerable;
(b)

The Organisation takes its obligations under the PDPA seriously and already

had in place various IT security measures and had embarked on a consultancy to ensure
its compliance with the PDPA even before the Incident;
(c)

The attackers were skilled hackers who utilised sophisticated hacking tools to

exploit a weak administrator password for the Tool which left the Database vulnerable
to unauthorised access. The Tool was never used by the Organisation’s staff and was
likely created during the development stage of Database;
(d)

Upon being informed of the Incident, the Organisation immediately made a

police report and promptly informed various public authorities including the Health
Sciences Authority and the Commission. The Organisation has also extended full
cooperation and provided prompt responses during the Commission’s investigations;
(e)

The Organisation promptly informed all affected individuals and there were no

registered complaints on the case;
(f)

Since the Incident, the Organisation had taken immediate steps to remove the

Database from the Website and put in place more security measures. This included
layered and restricted access, isolation of sensitive systems at the network level,
password training for staff, review and strengthening of standard operating procedures,
practising more stringent oversight of vendor actions, implementation of vulnerability
assessment and penetration testing regime for critical systems before deployment and
on a regular basis annually; and
(g)

The financial penalty that the Commissioner intended to impose seemed

excessive in light of previous decisions for similar or even more serious breaches.

Singapore Red Cross Society

[2020] SGPDPC 16

With respect to the representations on the nature and purpose of the Organisation, the

fact that the Organisation is a charity cannot be a mitigating factor, and its charitable status
cannot lower the standard expected of it in complying with its obligations under the PDPA.
The admitted failures on the Organisation’s part at [5] clearly fell short of the standard of
protection required for the Personal Data stored in the Database.
11

As for the Organisation’s representations comparing the present case to previous

decisions, it needs only to be said that each decision is based on the unique facts of each case.
The decision in each case takes into consideration the specific facts of the case so as to ensure
that the decision and direction(s) are fair and appropriate for that particular organisation.
The Commissioner’s Directions
12

Having carefully considered the representations, the Commissioner has decided to

reduce the financial penalty to the amount set out at [13]. The quantum of financial penalty has
been determined after due consideration of the appropriate weight to be given to:
(a)

the Organisation’s upfront voluntary admission of liability which significantly

reduced the time and resources required for investigations under the Expedited Breach
Decision procedure;3 and
(b)

the Organisation’s comprehensive remedial actions at [9(f)] to address the

inadequacies in its procedures and processes that contributed to the Incident.
13.

Taking into account all the relevant facts and circumstances, the Commissioner directs
the Organisation to pay a financial penalty of $5,000 within 30 days from the date of
the 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 the
financial penalty until the financial penalty is paid in full. Although a lower financial

See the Commission’s Guide on Active Enforcement at page 21

Singapore Red Cross Society

[2020] SGPDPC 16

penalty has been imposed in this case, this is exceptional and should not be taken as
setting any precedent for future cases.
14.

In view of the remedial measures taken by the Organisation, the Commissioner has not
imposed any other directions.

YEONG ZEE KIN
DEPUTY COMMISSIONER
FOR COMMISSIONER FOR PERSONAL DATA PROTECTION

",Financial Penalty,7bdf02b93a7a9d9facf04ceb3c80a66892a08642
95,95,1,952,"A financial penalty of $5,000 was imposed on Singapore Accountancy Commission for failing to put in place reasonable security arrangements to prevent the unauthorised access of 6,541 Singapore Chartered Accountant Qualification programme personnel and candidates’ personal data.","[""Protection"", ""Financial Penalty"", ""Professional"", ""Scientific and Technical"", ""Unintended recipient"", ""Email attachments""]",2020-08-03,https://www.pdpc.gov.sg/-/media/Files/PDPC/PDF-Files/Commissions-Decisions/Decision---Singapore-Accountancy-Commission---22062020.pdf,Protection,Breach of the Protection Obligation by Singapore Accountancy Commission,https://www.pdpc.gov.sg/all-commissions-decisions/2020/08/breach-of-the-protection-obligation-by-singapore-accountancy-commission,2020-08-03,"PERSONAL DATA PROTECTION COMMISSION
Case No. DP-1911-B5296
In the matter of an investigation under section 50(1) of the
Personal Data Protection Act 2012
And
Singapore Accountancy Commission

SUMMARY OF THE DECISION

On 18 November 2019, Singapore Accountancy Commission (the “Organisation”)
notified the Personal Data Protection Commission (the “Commission”) that a folder
containing personal data of 6,541 Singapore Chartered Accountant Qualification
programme personnel and candidates was mistakenly enclosed in emails sent to 41
unintended recipients between 12 June 2019 and 22 October 2019. The folder comprised
information such as names, National Registration Identification Card numbers, dates of
birth, contact details, education and employment information and Singapore Chartered
Accountant Qualification examination results. Following the incident, 41 unintended
recipients confirmed deletion of the email and folder they each received.

The Organisation admitted to a lack of robust processes to protect personal data when
sending emails. The staff involved in the sending of the emails were not informed of the
Organisation’s personal data policies as part of their induction training. The
Organisation’s data protection policies and procedures were not translated into security
arrangements for protection of personal data. There were, for example, no second-tier or

supervisory checks or technical measures to reduce the risk of sending content with
personal data to unintended parties at the time of the incident.

Following the incident, the Organisation undertook remediation. This included training
sessions on cybersecurity and personal data protection for all employees and revision of
policies and procedures on handling of personal data.

In the circumstances, the Deputy Commissioner for Personal Data Protection found that
the Organisation did not adopt reasonable steps to protect personal data in its possession
or under its control against unauthorised access. The Organisation was in breach of the
Protection Obligation under section 24 of the Personal Data Protection Act 2012 (the
“PDPA”).

The Organisation had made an admission of breach of the Protection Obligation under
the PDPA, cooperated with the Commission’s investigation and taken prompt remedial
actions.

On account of the above, the Organisation is directed to pay a financial penalty of $5,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. In
view of the remedial actions taken by the Organisation, the Commission will not issue
any other directions.

",Financial Penalty,3a8e7894f9d69623906f336fc824af00e156f58e
96,96,1,952,A warning was issued to Zero1 and IP Tribe respectively for failing to put in place reasonable security arrangements to prevent the unauthorised disclosure of 118 individuals’ personal data contained in invoices which were sent to incorrect recipients.,"[""Protection"", ""Warning"", ""Information and Communications"", ""Unintended recipient"", ""Duplication of batch ID"", ""Inadequate scoping of testing""]",2020-08-03,https://www.pdpc.gov.sg/-/media/Files/PDPC/PDF-Files/Commissions-Decisions/Decision---Zero1-and-IP-Tribe---07042020.pdf,Protection,Breach of the Protection Obligation by Zero1 and IP Tribe,https://www.pdpc.gov.sg/all-commissions-decisions/2020/08/breach-of-the-protection-obligation-by-zero1-and-ip-tribe,2020-08-03,"PERSONAL DATA PROTECTION COMMISSION
Case Nos. DP-1903-B3630, DP-1908-B4431
In the matter of an investigation under section 50(1) of the
Personal Data Protection Act 2012
And
1. Zero1 Pte. Ltd.
2. IP Tribe Pte Ltd

SUMMARY OF THE DECISION

On 22 March 2019, Zero1 Pte Ltd (the “Organisation”) voluntarily informed the
Personal Data Protection Commission (the “Commission”) that invoices
containing the personal data of their subscribers had been emailed to unintended
recipients (the “Incident”). Each invoice contained the name, address,
subscriber ID, mobile number, mobile charges, and the call details of any
international calls made by a subscriber (the “Personal Data”). Each email
contained a subscriber’s invoice which was unintendedly sent to another
subscriber instead.

The Organisation was a licensed Mobile Virtual Network Operation that provided
mobile services. It partnered Singtel Mobile Singapore Pte. Ltd. (“Singtel”),
which appointed IP Tribe Pte Ltd (“IPT”) to develop and deploy a Mobile Virtual
Network Enabler (the “1st Platform”) to manage subscriber accounts.

IPT ran the 1st Platform for the Organisation, including generating and sending
monthly emails to subscribers. IPT then subcontracted the provision of the billing
system within the 1st Platform to Openet Telecom Sales Limited (“Openet”). The
1st Platform was deployed in August 2018.

A replacement platform (the “New Platform”) was deployed in 2019. Openet
subcontracted 6D Technologies (“6D”) to migrate subscriber data from the 1st
Platform to the New Platform. In February 2019, 6D migrated the data of 12,000
to 15,000 subscribers.

The Incident was caused by Batch ID duplication. The Batch ID was a unique
number that tagged each subscriber to his name and email address. The
migration was staggered and some errors made it necessary to delete data

migrated earlier. However, due to a coding error, not all previously migrated data
had been deleted. The New Platform failed to recognise the Batch IDs that were
not deleted and re-issued the same Batch IDs. As a result, 118 invoices
belonging to subscribers with duplicated Batch IDs were affected. Since each
Batch ID determined the email address to which an invoice was sent, Batch ID
duplication resulted in the New Platform emailing the 118 invoices to the wrong
addresses.
6.

Before a new IT system or a change to an IT system goes live, pre-launch testing
is important to determine that the system would run as expected. The
Organisation, IPT and 6D jointly conducted pre-launch testing. The Organisation
as the end user, and IPT as the Organisation’s data intermediary, should have
scoped the pre-launch testing to include a simulation of expected scenarios. In
particular, the scenario in which migration to the New Platform is staggered and
a high volume of email addresses would have been assigned Batch IDs for the
sending of emails to the right subscriber (“Migration Scenario”).

However, in the pre-launch testing, the Migration Scenario was not catered for.
Only two test accounts were used to check that the New Platform could generate
and email invoices to the right parties. This was insufficient to simulate expected
usage. Consequently, the tests failed to surface this issue.

The proper scoping of pre-launching testing is important for the detection of
functionality issues that may put personal data at risk. In failing to simulate the
expected scenarios, in particular the Migration Scenario, the Organisation and
IPT failed to meet the reasonable standard required to discharge the Protection
Obligation.

Furthermore, the processes to ensure that the New Platform would issue unique
Batch IDs were inadequate. A date/time stamp could have been included as part
of each Batch ID to avoid duplication, which was implemented only after the
Incident.

10. In deciding to find the Organisation and IPT respectively in breach of the
Protection Obligation under the Personal Data Protection Act 2012 (the “PDPA”)
and to issue a Warning to each party, the Deputy Commissioner for Personal
Data Protection took into account the following:
a. Although the Organisation neither owned nor operated the New Platform, it
remained a data controller in control of its subscribers’ Personal Data.
b. IPT was the Organisation’s data intermediary in developing the New Platform,
which included migration of the personal data of subscribers. IPT relied on
Openet as its subcontractor, and the Batch ID duplication occurred as a result
of errors during the migration that was performed by 6D. Notwithstanding the
representations made by IPT, it retained a key role, together with the
Organisation, in scoping the pre-launch testing of the New Platform.

c. The tests proved to be inadequate and a reasonable opportunity to prevent
the Incident was missed. For this, both the Organisation and IPT bore
responsibility.
11. No directions are required as the Organisation and IPT had taken remedial
actions to address the gaps in security arrangements respectively.

",Warning,9289b77ccf9c91c7e895f86b99071f8723ce5faf
97,97,1,952,A warning was issued to Actstitude for failing to put in place reasonable security arrangements to prevent the unauthorised disclosure of individuals' personal data. Over 160 individuals uploaded their resumes to Actstitude's website and their personal data were accessible over the Internet.,"[""Protection"", ""Warning"", ""Information and Communications"", ""URL manipulation"", ""Vulnerability"", ""Access control"", ""Security""]",2020-08-03,https://www.pdpc.gov.sg/-/media/Files/PDPC/PDF-Files/Commissions-Decisions/Decision---Actstitude-Pte-Ltd---20032020.pdf,Protection,Breach of the Protection Obligation by Actstitude,https://www.pdpc.gov.sg/all-commissions-decisions/2020/08/breach-of-the-protection-obligation-by-actstitude,2020-08-03,"PERSONAL DATA PROTECTION COMMISSION
Case No. DP-1910-B5129
In the matter of an investigation under section 50(1) of the
Personal Data Protection Act 2012
And
Actstitude Pte Ltd

SUMMARY OF THE DECISION

Actstitude Pte Ltd (the “Organisation”) is a social media platform marketing agency.
It has a webpage allowing individuals interested in joining the Organisation to upload
their resumes. For each resume uploaded, a file was created with a Uniform Resource
Locator (“URL”) and stored in a database. Between August 2018 to October 2019,
over 160 individuals uploaded their resumes.

The Organisation, however, admitted that it did not put in place controls to restrict
access to the resume files. The URLs generated by the Organisation could also be
manipulated to access resume files uploaded by different individuals.

When the webpage was created on 5 July 2018, the Organisation did not conduct
vulnerability scanning as part of pre-launch testing; neither did the Organisation
conduct periodic security reviews. Such scans offer a reasonable chance of detecting
both the lack of access controls and the vulnerability of the URLs to manipulation.

The result of this failure to put in place access controls or to conduct security testing
was that Google indexed and disclosed the URLs when a search was made of the names
in the uploaded resumes. The URLs could then be manipulated to access the resumes of
other individuals. This led to a complaint to the Personal Data Protection Commission
on 25 October 2019.

The Deputy Commissioner for Personal Data Protection therefore found that the
Organisation did not adopt reasonable steps to protect personal data in its possession or
under its control against risk of unauthorised disclosure. The Organisation was in
breach of the Protection Obligation under section 24 of the Personal Data Protection
Act 2012. Upon consideration of the facts, a warning was issued to the Organisation.
No directions are required as the Organisation had taken action to address the gaps in
its security arrangements.

",Warning,f67b98aac5af051e0230fe4d74d422bae5c57230
98,98,1,952,"A warning was issued to Jean Yip Salon for failing to put in place reasonable security arrangements to prevent the unauthorised disclosure of personal data of its employees. As a result, the personal data of 28 individuals were accessible over the Internet.","[""Protection"", ""Warning"", ""Wholesale and Retail Trade"", ""Password"", ""Public access""]",2020-08-03,https://www.pdpc.gov.sg/-/media/Files/PDPC/PDF-Files/Commissions-Decisions/Decision---Jean-Yip-Salon-Pte-Ltd--13032020.pdf,Protection,Breach of the Protection Obligation by Jean Yip Salon,https://www.pdpc.gov.sg/all-commissions-decisions/2020/08/breach-of-the-protection-obligation-by--jean-yip-salon,2020-08-03,"PERSONAL DATA PROTECTION COMMISSION
Case No. DP-1907-B4281
In the matter of an investigation under section 50(1) of the
Personal Data Protection Act 2012
And
Jean Yip Salon Pte Ltd

SUMMARY OF THE DECISION

The Personal Data Protection Commission (the “Commission”) received a complaint
on 16 July 2019 about an employee system (the “System”) maintained by Jean Yip
Salon Pte Ltd (the “Organisation”) that was publicly accessible via the internet. The
personal data of 28 individuals disclosed via the System included their name, NRIC
number, residence status, date of birth, nationality, gender, mobile number and job
designation.

The Commission found that the Organisation did not adopt reasonable measures to
protect personal data in its possession against risk of unauthorised access. First, the
Organisation opened public access to a server without ascertaining what it hosted. As a
result, while enabling public access to the Customer Online Appointment Booking
System, it inadvertently also allowed access to the System (meant only for internal
use), which was also hosted on the same server. Second, there were no processes in
place to remove or deactivate unnecessary user accounts of the System. Finally, the

Organisation did not enforce a password policy for the user accounts of the System. As
such, the complainant was able to gain access to the System by simply using a wellknown and weak default username and password pair.

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
issued a warning to the Organisation. No directions were required as the Organisation
had implemented corrective measures that addressed the gaps in its security
arrangements.

",Warning,ebdd2c957a9673f4bcab7ed28d18a885209a8e04
99,99,1,952,A warning was issued to FWD Singapore for failing to put in place reasonable security arrangements to prevent the unauthorised disclosure of 71 individuals’ personal data contained in payment advice letters which were sent to incorrect recipients.,"[""Protection"", ""Warning"", ""Finance and Insurance"", ""Letters"", ""Logic error"", ""Code review""]",2020-08-03,https://www.pdpc.gov.sg/-/media/Files/PDPC/PDF-Files/Commissions-Decisions/FWD-Singapore-Pte-Ltd---Summary-of-Decision---13032020.pdf,Protection,Breach of the Protection Obligation by FWD Singapore,https://www.pdpc.gov.sg/all-commissions-decisions/2020/08/breach-of-the-protection-obligation-by-fwd-singapore,2020-08-03,"PERSONAL DATA PROTECTION COMMISSION
Case No. DP-1907-B4352
In the matter of an investigation under section 50(1) of the
Personal Data Protection Act 2012
And
FWD Singapore Pte Ltd

SUMMARY OF THE DECISION

The Personal Data Protection Commission (the “Commission”) was notified on 26 July
2019 by FWD Singapore Pte Ltd (the “Organisation”) of the unintended disclosure of
71 individuals’ (the “Affected Individuals”) personal data contained in 42 payment
advice letters sent to incorrect recipients between 20 June 2019 and 17 July 2019 (the
“Incident”).

The Incident arose from the Organisation’s attempt to fix a logic error in the system that
it used to generate payment advice letters. The error was introduced when a fix for an
earlier logic error was deployed. The Commission found that the second logic error could
have been detected if manual code review and unit testing had been conducted to a
reasonable standard.

The second logic error caused the extraction of incorrect mailing addresses for payment
advice letters in some circumstances. This resulted in the Affected Individuals’ names
and identification numbers in payment advice letters being sent to incorrect addresses.

The Organisation should have taken care in conducting its manual code review and unit
testing to avoid another logic error. In the circumstances, the Deputy Commissioner for
Personal Data Protection found the Organisation in breach of its Protection Obligation
under section 24 of the Personal Data Protection Act 2012 (the “PDPA”).

The Deputy Commissioner took into account the following factors in deciding to issue a
warning to the Organisation:

a. The Organisation had managed to retrieve letters containing the personal data of 67
out of the 71 Affected Individuals.

b. The Organisation voluntarily notified the Commission of the Incident.

c. The second logic error resulted in the extraction of incorrect mailing addresses only
in limited circumstances.

No directions are required as the Organisation took steps to improve its development
processes to prevent the recurrence of the Incident.

",Warning,bb248e5764c08e64f81212ce9f5a5c65012fd88c
100,100,1,952,"A financial penalty of $32,000 was imposed on CDP for failing to put in place reasonable security arrangements to prevent the unauthorised disclosure of individuals’ personal data. Mail sent by CDP were addressed to incorrect recipients.","[""Protection"", ""Financial Penalty"", ""Finance and Insurance"", ""Mail"", ""Unintended recipient""]",2020-08-03,https://www.pdpc.gov.sg/-/media/Files/PDPC/PDF-Files/Commissions-Decisions/Decision---The-Central-Depository-(Pte)-Limited-30032020.pdf,Protection,Breach of the Protection Obligation by CDP,https://www.pdpc.gov.sg/all-commissions-decisions/2020/08/breach-of-the-protection-obligation-by-cdp,2020-08-03,"PERSONAL DATA PROTECTION COMMISSION

[2020] SGPDPC 12
Case No DP-1905-B3847

In the matter of an investigation under section 50(1) of the
Personal Data Protection Act 2012
And
The Central Depository (Pte) Limited
… Organisation

DECISION

The Central Depository (Pte) Limited
[2020] SGPDPC 12
Tan Kiat How, Commissioner — Case No DP-1905-B3847
30 March 2020
Introduction
1

The Central Depository (Pte) Limited (the “Organisation”) provides integrated

clearing, settlement and depository facilities for its account holders (“CDP Account Holders”)
in the Singapore securities market. On 3 May 2019, the Organisation notified the Personal Data
Protection Commission (the “Commission”) that dividend cheques of some CDP Account
Holders had been mailed to outdated addresses, resulting in the disclosure of their personal
data to other individuals.
Facts of the Case
2

Prior to 10 December 2018, the Organisation used a software known as the Post Trade

System (“PTS”) for the purposes of post trade processing. The Organisation developed and
customised additional modules that interfaced with PTS, including a module for the printing
of dividend cheques (“Dividend Cheque Module”). The Dividend Cheque Module was used
to automate the generation of dividend cheque mailers (i.e. mailers enclosing dividend cheques
to be posted to CDP Account Holders).
3

Subsequently, the Organisation purchased another software, the New Post Trade

System (“NPTS”) to replace the PTS. In comparison to the PTS, the NPTS facilitated record
keeping that was more comprehensive. The PTS only recorded a CDP Account Holder’s latest
address, while the NPTS kept records of the CDP Account Holder’s updated address as well
as historical addresses.1 Arising from the new feature of the NPTS that kept records of CDP
Account Holders’ updated addresses and historical addresses, the Organisation updated the
programming logic of the Dividend Cheque Module (and all other modules that required
retrieving of addresses) to extract the CDP Account Holders’ updated addresses.

As there was only one address for each CDP Account Holder stored in the PTS, a query for the address would
always extract that address of the CDP Account Holder.

Prior to migration from PTS to NPTS, the Organisation conducted several tests, which

included the following:
(a)

A test for the change of address for the module that generated notification letters

acknowledging a change of address. This included checking that the notification letters
extracted the updated address (the “Notification Letters Test”);
(b)

A test for the extraction of CDP Account Holders’ personal data for the

Dividend Cheque Module. The scope of this test did not include the scenario of change
of address (i.e. whether the Dividend Cheque Module would extract the updated address
in the event a CDP Account Holder changed its address) (the “Dividend Cheque
Module Test”); and
(c)

Manual code review of the additional modules (including the Dividend Cheque

Module).
5

On 10 December 2018, the Organisation migrated from PTS to NPTS. As the tests

mentioned at [4] did not detect any errors, the Organisation was unaware that the Dividend
Cheque Module may not consistently extract a CDP Account Holder’s updated address.
6

On 20 March 2019, a CDP Account Holder complained that the Organisation had

mailed a cheque for dividends to an outdated address (“First Incident”). The Organisation
commenced investigations immediately. However, the Organisation’s technical team was
unable to replicate the error and identify the issue that caused the First Incident. The results for
the Dividend Cheque Module Test returned the correct addresses, including the complainant’s
correct address.
7

Subsequently, on 12 April 2019, the Organisation’s customer service team received an

email from the Monetary Authority of Singapore (“MAS”) in relation to a complaint (“Second
Incident”). Meanwhile, notwithstanding that the Organisation’s technical team was unable to
identify the issue that caused the First Incident, to further reinforce the programming logic,
they introduced a defensive measure with a clause to consistently extract the updated addresses
(the “Fix”). On 20 April 2019, the Organisation deployed the Fix into the production
environment.

After several rounds of correspondence and additional information provided by MAS

on 30 April 2019 in relation to the Second Incident, the Organisation realised that the issue
pertaining to the First Incident and Second Incident may have a wider impact than originally
anticipated. The Organisation conducted further investigations which revealed that all of the
modules involving the retrieval of addresses were correctly coded except the Dividend Cheque
Module. The error in the code in the Dividend Cheque Module (which resulted in the
programme logic not consistently extracting a CDP Account Holder’s updated address) had
caused the First Incident and Second Incident. Due to the implementation of the Fix as
mentioned at [7], the error had been permanently resolved by this time.
9

According to the Organisation, 542 CDP Account Holders were due to receive dividend

cheque mailers, and had previously updated their addresses. Out of the 542 CDP Account
Holders whose personal data was at risk of unauthorised disclosure, the Organisation confirmed
that 331 CDP Account Holders had presented their dividend cheques, indicating that their
dividend cheque mailers had been sent to the correct addresses. By deduction, there were
accordingly 211 CDP Account Holders (“Affected Individuals”) whose dividend cheque
mailers were sent to outdated addresses.
10

The information disclosed in the dividend cheque mailers (collectively, “Disclosed

Data”) were:

(a)

Name of client;

(b)

NRIC number;

(c)

Central Depository (Pte) Limited (“CDP”) account number;

(d)

Name of security;

(e)

Quantity of security held; and

(f)

Dividend amount.

During the course of its investigations into the First Incident and Second Incident, the

Organisation took the following remedial actions:

(a)

On 20 April 2019, introduced an additional measure to ensure that the updated

address of CDP Account Holders would be extracted in the Dividend Cheque Printing
Module;
(b)

Reviewed all modules which interfaced with NPTS and which involved the

extraction of addresses to confirm that the error was specific only to the Dividend
Cheque Module; and
(c)

Re-issued replacement cheques and explanation letters to the Affected

Individuals.
12

In addition, the Organisation will also be conducting refresher training to ensure that

its teams report issues under their respective purview as soon as practicable (even when similar
type of issues had previously been raised), so that necessary follow up action may be taken.
Findings and Basis for Determination
Whether the Organisation had contravened section 24 of the PDPA
13

It is undisputed that the Disclosed Data constitutes “personal data” as defined in section

2(1) of the Personal Data Protection Act 2012 (“PDPA”), and the Organisation had possession
and/or control over the Disclosed Data at all material times.
14

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. The fact that the Disclosed Data included NRIC numbers and personal data of a financial
nature (i.e. CDP account number, name and quantity of security held, and dividend amount) is
relevant in assessing the standard of reasonable security arrangements required. As emphasized
in previous decisions, when it comes to the protection of personal data of a sensitive nature,
stronger security measures must be put in place due to the actual or potential harm, and the
severity of such harm, that may befall an individual from an unauthorised use of such data. 2
Having in mind the sensitivity of the Disclosed Data, the Organisation failed to put in place
2

See for example, Re Credit Counselling Singapore [2017] SGPDPC 18 at [25]; Re Aviva Ltd [2018] SGPDPC
4 at [17]; DS Human Resource Pte. Ltd. [2019] SGPDPC 16 at [9(c)]; and AIA Singapore Private Limited
[2019] SGPDPC 20 at [12].

reasonable security arrangements to protect the Disclosed Data for the reasons explained
below.
15

When the Organisation migrated from PTS to NPTS, it had an obligation to conduct

proper and adequate testing of the NPTS and its implementation that simulated real world usage
of the system. This was critical in order to prevent errors from compromising the security of
the Disclosed Data. In particular, and as mentioned at [3], the NPTS had a new feature which
kept records of both the updated addresses of CDP Account Holders as well as their historical
addresses, and the Organisation was relying on the NPTS and its customised additional
modules to extract the correct address when generating the dividend cheque mailers.
16

The Commission’s investigations revealed that the Organisation failed to conduct

sufficient testing before migrating from PTS to NPTS for the following reasons:
(a)

First, the scope of the testing for the Dividend Cheque Module was too narrow

and did not include the scenario of change of address. This omission was unacceptable
given that (i) change of address was a known scenario (which was tested in the module
with respect to generation of notification letters that acknowledged change of address);
and (ii) the Organisation relied on the Dividend Cheque Module to extract the updated
address and automate the generation of dividend cheque mailers;
(b)

Secondly, the Organisation should have tested the Dividend Cheque Module in

an environment that simulated real world usage of the system. This required the
Organisation to not only scope the tests to include the change of address scenario, but
also to have a sufficient number of test cases to properly test these scenarios; and
(c)

Thirdly, the Organisation had conceded that there was a “reasonable chance”

that the error in the Dividend Cheque Module may have been detected if the scope of
the tests had included the change of address scenario with a sufficient number of tests
cases.
17

For the reasons above, the Commissioner found the Organisation in breach of section

24 of the PDPA.

Representations by the Organisation
18

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

amount of financial penalty that was to be imposed. The Organisation raised the following
factors for consideration:
(a)

The Organisation had expended its best efforts in testing:
(i)

Prior to migration from PTS to NPTS, the Organisation carried out the

Notification Letter Test and the Dividend Cheque Module Test. Both tests did
not return any errors. In view of this, the Organisation did not contemplate
further targeted testing at the material time.
(ii)

Even if the Organisation had expanded the scope of the Dividend

Cheque Module Test to cover the change of address scenario and increased the
relevant test cases, such testing may have still failed to reveal the defect. In this
regard, after being informed of the First Incident, the Organisation was unable
to replicate the error through repeated testing with real world cases.
(b)

There was no risk of actual financial loss.
(i)

The dividend cheques were made out to the names of the Affected

Individuals and could only be encashed into accounts bearing such names.
(ii)

The Disclosed Data of each Affected Individual was disclosed only to a

single recipient, as opposed to the world at large. The Disclosed Data was also
insufficient, in and of itself, to be used by a recipient to impersonate or execute
any transaction in the name of an Affected Individual.
(iii)

The Organisation used a specific envelope for the mailing of dividend

cheques to minimise unauthorised access to the Disclosed Data, save in wilful
circumstances. Each envelope was marked “Private & Confidential” and “To be
opened by addressee only”. A return address was printed on the face of the
envelope, to cater for the event that the letter was not properly delivered to the
addressee.

(c)

Upon establishing the number of dividend cheques affected on 3 May 2019, the

Organisation promptly notified the Affected Individuals and the Commission. The
Organisation also took proactive and prompt remedial steps at [11].
(d)

The financial penalty imposed should be consistent with the Commission’s

previous decisions and commensurate with the scale of the Incident. Taking into
consideration the number of Affected Individuals in the present case and financial
penalties imposed in the Commission’s previous decisions involving similar number of
affected individuals, a warning would suffice. In the alternative, the Organisation
submitted that any financial penalty imposed should not exceed $5,000.
19

Having carefully considered the representations, the Commissioner has decided to

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

As explained in [15] to [16], the Organisation failed to conduct sufficient testing

before migrating from PTS to NPTS. The module that generated notification letters
acknowledging a change of address was coded independently from the Dividend
Cheque Module. The Organisation should not have relied on test results from the
Notification Letters Test as assurance that there were no errors in the Dividend Cheque
Module, and it would consistently extract a CDP Account Holder’s updated address.
(b)

The Organisation’s representations that there was no risk of financial loss

cannot be accepted. Although the risk of financial loss was reduced because the
dividend cheques were made out to the names of the Affected Individuals, there was
still a risk of fraud i.e. the unauthorised individuals who received the dividend cheque
mailers could have fraudulently altered the names on the dividend cheques and
presented them for encashment. In addition, for the period between the Incident and the
Organisation issuing the replacement cheques, the Affected Individuals would have
been deprived of the use of funds they would have otherwise access to. As for the
Organisation’s representations on the specific envelopes used for the mailing of
dividend cheques, the fact that the dividend cheques mailers were sent to unauthorised
individuals meant that there was a risk of further unauthorised access, use and
disclosure of the Disclosed Data.

(c)

The Organisation’s voluntary notification of the Incident to Affected

Individuals and the Commission, as well as the Organisation’s proactive and prompt
remedial steps had already been taken into consideration in determining the financial
penalty at [21].
(d)

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

to earlier decisions, it needs only to be said that each decision is based on the unique
facts of each case. The decision in each case takes into consideration the specific facts
of the case so as to ensure that the decision and direction(s) are fair and appropriate for
that particular organisation.
The Commissioner’s Directions
20

In the assessment of the breach and determination of the directions, if any, to be

imposed on the Organisation under section 29 of the PDPA, the fact that the Affected
Individuals were put at risk of actual financial loss was an aggravating factor. The dividend
cheques mailers were sent to outdated addresses and there was a risk that they may have been
banked in by unauthorised persons. The Affected Individuals would also have been deprived
of the use of the funds they would have otherwise access to, had they received and banked in
the dividend cheques. On the other hand, the following mitigating factors were also considered:
(a)

the Organisation took prompt remedial actions to rectify the error and mitigate

the effects of the breach; and
(b)
21

the Organisation was cooperative with the Commission’s investigations.

In consideration of the relevant facts and circumstances, the Commissioner hereby

directs the Organisation to pay a financial penalty of $32,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. The Commissioner has not set out any further
directions given the remediation measures already put in place.

YEONG ZEE KIN
DEPUTY COMMISSIONER
FOR COMMISSIONER FOR PERSONAL DATA PROTECTION
9

",Financial Penalty,c533793aa9a8e3bfcebfd59e65b4ee2051754090