_commit_at,_commit_hash,_id,_item,_version,_commit,description,tags,date,pdf-url,nature,title,url,timestamp,pdf-content,decision,_item_full_hash,_changed_columns
2023-10-01T11:02:10+08:00,fbd32491db44d3d0c97aa12a99cefd61ec954264,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,"[""pdf-content"",""timestamp"",""decision"",""pdf-url"",""tags"",""nature"",""url"",""title"",""date"",""description""]"
2023-10-01T11:02:10+08:00,fbd32491db44d3d0c97aa12a99cefd61ec954264,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

1

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

5

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.

6

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;

3

(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;

b)

identify reliable and well-trained personnel responsible for ensuring information
security;

c)

implement robust policies and procedures for ensuring appropriate levels of
security for personal data of varying levels of sensitivity; and

d)

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)

1

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)

5

b)

who within the organisation has access to the personal data; and

c)

whether the personal data is or will be held or used by a third party on behalf of
the organisation.”
(emphasis added)

12

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)

6

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.

7

17

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

8

",Warning,4095cd546dacd60ce1e477d8e6d816e126775088,"[""pdf-content"",""timestamp"",""decision"",""pdf-url"",""tags"",""nature"",""url"",""title"",""date"",""description""]"
2023-10-01T11:02:10+08:00,fbd32491db44d3d0c97aa12a99cefd61ec954264,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

1

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

2

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.

3

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”).

2

Personal data collected by the Organisation

4

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”)

5

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.

6

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:

3

(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

7

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.

4

8

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.

9

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.

10

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.

11

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

12

Following the Incident, the remedial actions of Bossini Holdings and the Organisation

included:

5

(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

6

(l)

Engaging a third-party security operations centre to monitor the Bossini group’s

network infrastructure.

13

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

14

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.

15

For the reasons set out below, the Organisation was determined to have breached both

the Transfer Limitation and Protection Obligations.
7

16

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”).

17

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

8

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

18

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.

19

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.

20

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.

1

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.

9

Whether the Organisation breached the Protection Obligation

21

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.

22

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.

23

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.

24

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.

25

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.

26

In the circumstances, the Organisation was determined to have breached the Protection

Obligation.

11

The Deputy Commissioner’s Directions

27

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

12

",Directions,0705137f0dd7129af2528c049cc49cf5edda8502,"[""pdf-content"",""timestamp"",""decision"",""pdf-url"",""tags"",""nature"",""url"",""title"",""date"",""description""]"
2023-10-01T11:02:10+08:00,fbd32491db44d3d0c97aa12a99cefd61ec954264,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

2

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;

b.

A malware scan was run on the Server, and all unnecessary files were removed;

c.

The operating system of the Server was updated and the root password was
changed;

d.

A website security scanning tool was installed to conduct security scanning of the
Portal; and

e.

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

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 the Testing Database.
7

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.

4

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.”

15

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.

5

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

6

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.

7

25

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

8

","Financial Penalty, Directions",573fcfa5db4c96ff1bb6711b02e1ab2d1d9cd20a,"[""pdf-content"",""timestamp"",""decision"",""pdf-url"",""tags"",""nature"",""url"",""title"",""date"",""description""]"