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

1.

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

2.

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.

3.

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

4.

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.

5.

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.

6.

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.

7.

In the circumstances, the Organisation is found to have breached section 24 of the PDPA.

8.

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:

i.

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;

v.

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;

9.

ix.

9th instalment of $750 on 1 May 2022;

x.

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

2

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

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

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.

3

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)

In

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.

5

SAP Asia Pte. Ltd.

15

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

19

[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

7

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

10

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

1.

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.

2.

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

3.

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.

4.

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.

5.

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.

6.

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

1

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

2

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

2

personal data (comprising names and user account identifications) were exfiltrated by the threat
actor.

Findings and Basis for Determination

3

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.

4

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

3

across the group. The Transfer Regulations 2014 (and 2021) support the adoption of intragroup agreements and binding corporate rules in the following manner.

5

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.

6

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

7

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.

4

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.

8

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.

5

The Deputy Commissioner’s Directions

9

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

3

Refer to Regulation 11 of Personal Data Protection Regulations 2021, which is applicable at the present time.

6

",Directions,3b598c8a7be71e58fadf5f81e6bf2476ad13c791,"[""pdf-content"",""timestamp"",""decision"",""pdf-url"",""tags"",""nature"",""url"",""title"",""date"",""description""]"