_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,33,33,1,952,"A financial penalty of $12,500 was imposed on PINC for failing to put in place reasonable security arrangements to protect the personal data in its possession. Directions were also issued to PINC to develop and implement internal data protection policies and practices to comply with the PDPA and to ensure no copies of database were stored on employees' personal computers.","[""Accountability"", ""Protection"", ""Financial Penalty"", ""Directions"", ""Wholesale and Retail Trade"", ""No Policy""]",2022-05-19,https://www.pdpc.gov.sg/-/media/Files/PDPC/PDF-Files/Commissions-Decisions/Decision---PINC-Interactive-Pte-Ltd---04022022.pdf,"Accountability, Protection",Breach of the Accountability and Protection Obligations by PINC Interactive,https://www.pdpc.gov.sg/all-commissions-decisions/2022/05/breach-of-the-accountability-and-protection-obligations-by-pinc-interactive,2022-05-19,"PERSONAL DATA PROTECTION COMMISSION

[2022] SGPDPC 1

Case No. DP-2002-B5827

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

And

PINC Interactive Pte. Ltd.

… Organisation

DECISION

Page 1 of 9

PINC Interactive Pte. Ltd.
[2022] SGPDPC 1
Lew Chuen Hong, Commissioner — Case No. DP-2002-B5827
4 February 2022
Introduction
1

On 2 February 2020, the Personal Data Protection Commission (“the

Commission”) received feedback about a Twitter post dated 31 January 2020 which
revealed that the personal data of users of www.pincstyle.com had been exposed. The
tweet included a snapshot of the data (“the Incident”). The Commission commenced
investigations into the Incident thereafter.
Facts of the Case
2

The website www.pincstyle.com was created and managed by PINC Interactive

Pte. Ltd. (“the Organisation”) at the material time. Investigations revealed that
sometime in October 2019, a database comprising 252,813 records was accessed
and exfiltrated from the Organisation’s staging servers (the “Staging Database”). The
Staging Database is a synthetic database containing personal data of 3,916 actual
users, while the remaining 248,897 records were fake or “dummy” data modelled after
the real data. The synthetic database was used to facilitate development and testing
on the staging servers. The personal data from the 3,916 actual users that were
exposed in the Incident included the name, username, email address, contact number
(for some users) and a password hash. For completeness, the 3,916 user records in
the Staging Database is equivalent to 1.6% of the Organisation’s total database of
252,813 user records.

Page 2 of 9

3

Investigations revealed two likely causes of the Incident. First, the developers,

who are the Organisation’s employees, had retained a copy of the Staging Database
on their own personal devices, and the database was exfiltrated when the developers’
computers were compromised. The Organisation stated that while they had instructed
the developers to use strong passwords, the developers were left to manage the
security settings on their own computers, and only had antivirus software installed.
4

Second, unauthorised access may have occurred from May 2019 to October

2019 when the Organisation did not require authentication for the Application
Programming Interface (“API”) under testing (“Staging API”), which pointed to the
Staging Database containing the personal data of real users, despite the Staging
Database being accessible over the Internet. The Organisation only implemented
access key authentication from October 2019 onwards.
Remedial actions
5

Following the Incident, the Organisation took the following remedial actions:
a.

Updated the API with new authentication keys;

b.

Limited the access of authentication keys to only the senior developers;

c.

A password reset was initiated for affected users via email; and

d.

Developers were instructed to delete their local copy of the Staging
Database and scan their own computers for malware.

Findings and Basis for Determination
Whether the Organisation contravened the Protection Obligation
6

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

organisation to protect personal data in its possession or under its control by making
reasonable security arrangements to prevent unauthorised access, collection, use,
Page 3 of 9

disclosure, copying, modification, disposal or similar risks (the “Protection
Obligation”). For the reasons set out below, the Organisation failed to implement
reasonable security arrangements to protect the personal data in the Staging
Database.
7

Firstly, the Organisation had failed to accord adequate protection to the

personal data by allowing their employees, i.e. the developers, to store local copies of
the Staging Database in their own personal devices, without implementing any
additional security requirements. Allowing their employees to store the Staging
Database in their own personal devices constituted a breach of the Protection
Obligation, given that the Staging Database did not merely contain purely synthetic
data, but also the personal data of real users.
8

Secondly, the Organisation was also in breach of the Protection Obligation as

it merely instructed its employees not to use weak passwords on their personal
devices, and left it to each individual employee to decide if and what level of security
measures ought to be implemented on their own personal devices to protect the
personal data. Indeed, even though the developers had purportedly installed antivirus
software on their own personal devices, the Organisation was unable to provide the
product name, version, or the frequency of the antivirus updates that the developers
supposedly implemented on their end when questioned.
9

In Learnaholic Pte. Ltd.1, the Organisation was found in breach of section 24 of

the PDPA as the personal data affected had been sent to and stored in the work email
account belonging to the Organisation’s representative in an unencrypted form. After
completing the task at hand, the representative failed to delete the email containing
the personal data that he received. Instead, the representative kept the email
containing the personal data, in case he needed it in future. As a result, the hacker
had free rein to the personal data affected once he obtained access to the email

1 [2019] SGPDPC 31.

Page 4 of 9

account. In a similar vein, the Organisation here has failed to adopt adequate security
measures when it simply allowed its employees to retain a copy of the Staging
Database on their own personal devices, without putting any thought to the security
measures that ought to be implemented to protect the personal data.
10

Finally, while we appreciate that the Organisation wanted the Staging API to

mirror the production environment, it was not a reasonable “protection” measure to
commingle synthetic data with the personal data belonging to real users, without
processing the personal data of the real users before doing so, as this meant that the
Staging Database contained the data of real users. Having decided to use personal
data belonging to real users in the Staging Database, the Organisation has breached
the Protection Obligation by failing to require authentication before the Staging API
could be accessed. If the Organisation’s intention was not to require authentication for
the Staging API, the Organisation should have chosen to use only synthetic data in
the Staging Database. In How to Guard Against Common Types of Data Breaches
(the “Handbook”),2 the Commission identified the five most common gaps in ICT
system management and processes, and observed at page 11 of the Handbook that:
“Out of convenience, many organisations use production data for system
testing in their test environments. But as test environments tend to be much
less secured, there is a high risk of data breach in a test environment.”
11

In the Handbook, the Commission explained that synthetic data can be

generated either from scratch using commercial tools or by anonymising production
data, and recommended that organisations can create synthetic data (i.e. fake
personal data or data anonymised from real data) for development and testing
purposes in non-production environments instead of using real data.

2 https://www.pdpc.gov.sg/news-and-events/announcements/2021/05/handbook-on-how-to-guard-

againstcommon-types-of-data-breaches-now-available

Page 5 of 9

12

In this case, the Organisation could have chosen to use 100% synthetic data

or anonymise the personal data before using them if it did not wish to require
authentication for the Staging API. In light of the above, we are also of the view that
the Organisation breached the Protection Obligation by using personal data belonging
to real users in the Staging Database, but failing to require authentication before the
Staging API could be accessed.
Whether the Organisation contravened the Accountability Obligation
13

Section 12(a) of the PDPA requires an organisation to develop and implement

policies and practices that are necessary for the organisation to meet its obligations
under the PDPA (the “Accountability Obligation”).
14

The Organisation admitted that they did not have any data protection policies

or practices in place for their “non-technical” employees, who have access to “public
user data”. In its reply, the Organisation drew a distinction between its “technical” and
“non-technical staff”, and stated that for the “technical” staff, the data protection
policies in place extended to the Organisation’s team lead providing a briefing to the
“technical” staff of the system, rules for branch creation and the code standard during
onboarding. The information provided by the Organisation to its “technical” staff, during
their onboarding, serves merely to facilitate the performance of these employees’ core
duties, and cannot be equated with or amount to data protection policies or practices.
15

Indeed, the Organisation’s reply reflects a lack of understanding of what data

protection policies and processes seek to achieve and implement. We have previously
stressed the critical role that data protection policies and practices play in increasing
awareness and ensuring accountability of an organisation’s obligations under the
PDPA in Re Aviva Ltd3. We also explained in Re Singapore Cricket Association4 that
data protection policies and practices ensure that employees will be able to better

3 [2018] PDP Digest 245 at [32].
4 [2019] PDP Digest 270 at [19].

Page 6 of 9

protect personal data when they are first able to recognise a matter as one involving
data protection.
16

Given the Organisation’s reply, it follows that the Organisation did not in fact

have any data protection policies or processes in place to guide their employees on
how to comply with the PDPA in carrying out their work functions. The Organisation
has therefore breached the Accountability Obligation.
The Commissioner’s Directions
17

In determining whether to impose a financial penalty on the Organisation

pursuant to section 48J(1) of the PDPA, and if so, the amount of such financial penalty,
the factors listed at section 48(6) of the PDPA were taken into account, as well as the
following aggravating and mitigating factors:
Aggravating Factors
(a)

The Organisation allowed its employees to keep local copies of the

Staging Database on their personal devices, without considering and
undertaking any security measures needed to protect the personal data of real
users;
Mitigating Factors
(b)

The Organisation was cooperative in the course of investigations and

had provided prompt responses to PDPC’s requests for information; and
(c)

The Organisation was implemented remedial actions to address the

Incident.
18

In the course of settling this decision, the Organisation made representations
on the amount of financial penalty that the Commissioner intended to impose.

Page 7 of 9

The Organisation raised the following factors for the Commissioner’s
consideration:
(a)

The Organisation had engaged an external consultancy firm to ensure

that its obligations under the PDPA are upheld to the highest standards with
periodic audits, training and risk assessments; and
(b)

The Organisation was incorporated in 2018 and is still a relatively young

company. Since its inception, it had been suffering significant losses in its
operation.
19

Having considered the Organisation’s representations, as well as all the

relevant factors of this case, the Commissioner hereby decided to impose a reduced
financial penalty of $12,500 on the Organisation. The quantum of financial penalty has
been calibrated and reduced after due consideration of the Organisation’s financial
circumstances, bearing in mind that any financial penalty imposed should not be
crushing or cause undue hardship on organisations.
20

Taking into account all the relevant facts and circumstances, the Commissioner

hereby:
(a)

Requires the Organisation to pay a financial penalty of $12,500 within

30 days from the date of the relevant notice accompanying this decision, failing
which interest at the rate specified in the Rules of Court in respect of judgment
debts shall accrue and be payable on the outstanding amount of such financial
penalty until the financial penalty is paid in full;
(b)

Directs the Organisation to:
(i)

Develop and implement internal data protection policies and

practices to comply with the PDPA within 60 days of the relevant
direction accompanying this decision;

Page 8 of 9

(ii)

Ensure that no local copies of the database are stored on the

personal computers of any employees (including both developers and
senior

developers)

within

60

days

of

the

relevant

direction

accompanying this decision; and
(iii)

To notify the Commission within 1 week of the completion of this

direction.
21

Although the Commissioner has imposed a lower financial penalty on the

Organisation in this case, the financial penalty was arrived at after considering the
dismal state of the Organisation’s finances, and should be confined to the specific
facts of this case.

YEONG ZEE KIN
DEPUTY COMMISSIONER
FOR COMMISSIONER FOR PERSONAL DATA PROTECTION

Page 9 of 9

","Financial Penalty, Directions",d2cda7ac80cc4638223955ef382304ee06a36b98,"[""pdf-content"",""timestamp"",""decision"",""pdf-url"",""tags"",""nature"",""url"",""title"",""date"",""description""]"
2023-10-01T11:02:10+08:00,fbd32491db44d3d0c97aa12a99cefd61ec954264,66,66,1,952,"Chapel of Christ the Redeemer failed to put in place reasonable measures to protect its members' personal data. Further, it did not have written policies and practices necessary to comply with the PDPA.","[""Accountability"", ""Protection"", ""Directions"", ""Others"", ""No Policy"", ""Access control"", ""Indexing""]",2021-04-15,https://www.pdpc.gov.sg/-/media/Files/PDPC/PDF-Files/Commissions-Decisions/Decision---Chapel-of-Christ-the-Redeemer---290121.pdf,"Accountability, Protection",Breach of the Protection and Accountability Obligations by Chapel of Christ the Redeemer,https://www.pdpc.gov.sg/all-commissions-decisions/2021/04/breach-of-the-protection-and-accountability-obligations-by-chapel-of-christ-the-redeemer,2021-04-15,"PERSONAL DATA PROTECTION COMMISSION
Case No. DP-2010-B7132

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

SUMMARY OF THE DECISION

1.

On 6 October 2020, Chapel of Christ the Redeemer (the “Organisation”) informed the
Personal Data Protection Commission (the “Commission”) that a file (the “File”)
containing personal data of 815 members’ name, NRIC, address, date of birth, marital
status, email address, mobile and residential phone number was inadvertently disclosed
online.

2.

Investigations revealed that a staff had accidentally uploaded the File (which was
supposed to be an internal document) onto the sub-directory on 24 November 2019. The
Organisation only discovered the matter on 8 September 2020 when a member of the
Organisation performed a Google search of another member’s name and found a Google
search result of the File.

3.

The Organisation admitted that there were no access controls to the sub-directory prior
to the incident as the sub-directory was intended to be accessible to public. As a result,
the File was indexed by search engines and showed up in online search results. The
Organisation also admitted that at the time of the incident, the Organisation had not
developed any internal policies and practices to ensure compliance with the Personal
Data Protection Act 2012 (the “PDPA”). In particular, there was no system of checks for
the uploading of files on the Organisation’s website.

4.

Fortuitously, it appeared that the access to the File was minimal – based on Google
Analytics Report, save for the Organisation’s member who discovered the File on the
internet on 8 September 2020, there was only one other access to the File on 9 December
2019, and the access only lasted for approximately 1 minute.

5.

Following the incident, the Organisation disabled the search engine indexing to the subdirectory, password-protected all files with members’ data, and implemented a weekly
check of all files uploaded onto the website to detect any accidental uploading of
incorrect files; and a policy to delete files that are on the website for more than three
months. The Organisation has also informed the Commission that it intends to engage a
consultant to conduct PDPA training for its staff, as well as to review the data protection
processes within the Organisation to ensure compliance with the PDPA.

6.

In view of the facts stated at [3] above, the Deputy Commissioner for Personal Data
Protection found the Organisation in breach of section 12 of the PDPA (the obligation to

develop and implement data protection policies and practices), and section 24 of the
PDPA (the obligation to protect personal data in an organisation’s possession or under
its control by making reasonable security arrangements).

7.

In determining the directions to be imposed on the Organisation under section 29 of the
PDPA, the following factors were taken into account:

(a) The Organisations had voluntarily notified the Commission of the incident, fully
cooperated with the Commission’s investigations and implemented prompt remedial
measures to address the breach; and

(b) There was minimal access to the File and no evidence that the personal data had been
misused.

8.

In the circumstances, the Deputy Commissioner would not be imposing any financial
penalty on the Organisation. However, in light of the Organisation’s lack of the necessary
data protection policies and practices, the Deputy Commissioner hereby directs the
Organisation to:

(a) Develop and implement internal data protection policies and practices to comply
with the provisions of the Act within 90 days from the date of the direction, and

(b) Inform the Commission within 1 week of implementation of the above.

",Directions,3af9997c53409121b23cd38f9ec106f784e3648c,"[""pdf-content"",""timestamp"",""decision"",""pdf-url"",""tags"",""nature"",""url"",""title"",""date"",""description""]"
2023-10-01T11:02:10+08:00,fbd32491db44d3d0c97aa12a99cefd61ec954264,68,68,1,952,"Jigyasa was found in breach of the PDPA. First, Jigyasa failed to put in place reasonable measures to protect employee assessment reports on its website. Second, it did not appoint a data protection officer. Lastly, it did not have written policies and practices necessary to ensure its compliance with the PDPA.  An application for reconsideration was filed against the decision in Re Jigyasa [2020] SGPDPC 9. Upon review and careful consideration of the application, directions in the decision were varied in the Reconsideration Decision and a financial penalty of $30,000 was imposed on Jigyasa.","[""Accountability"", ""Protection"", ""Financial Penalty"", ""Professional"", ""Scientific and Technical"", ""No Policy"", ""No DPO"", ""Public access"", ""No pre-launch testing""]",2021-03-11,https://www.pdpc.gov.sg/-/media/Files/PDPC/PDF-Files/Commissions-Decisions/Decision---Jigyasa---30032020.pdf,"Accountability, Protection",Breach of the Protection and Accountability Obligations by Jigyasa,https://www.pdpc.gov.sg/all-commissions-decisions/2021/03/breach-of-the-protection-and-accountability-obligations-by-jigyasa,2021-03-11,"PERSONAL DATA PROTECTION COMMISSION

[2020] SGPDPC 9
Case No DP-1707-B0922

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

And

Jigyasa
(UEN: 52948595L)

… Organisation

DECISION

1

Jigyasa
[2020] SGPDPC 9
Tan Kiat How, Commissioner — Case No DP-1707-B0922
30 March 2020

Introduction
1

This case concerns the unauthorised disclosure of employee assessment reports, such
as 360 Feedback Reports and evaluation reports (collectively, the “Reports”), on the
website (“Website”) of Jigyasa (the “Organisation”), a human resource and
management consultancy business.

Material Facts
2

The Organisation is a business operated by a sole proprietor with one part-time
employee. The Reports were generated based on survey results collected by the
Organisation via its web application (the “Web Application”) and stored in a folder on
the server which hosted the Web Application. Reports documented 360 degree feedback
on employees of the Organisation’s clients, based on evaluation by their subordinates,
supervisors and/or peers. The feedback included character qualities, for example
whether they were considered fair, honest, reliable and trusted, demonstrated
professional behaviour at all times or had good technical knowledge. Each of these
character qualities was given an average rating from a scale of 1 to 10, with 9-10 being
an exceptional strength and 1-2 being below expectations. These Reports
comprehensively set out such information for each named individual employee of the
Organisation’s clients. There is also a section which provides verbatim comments from
respondents (e.g. “handle more complex responsibilities”, “slower support”). Some of
the Reports also included individual employees’ qualities, such as leadership, integrity,
decision-making, initiative, and professional disposition, ranked against their
colleagues.

2

3

On 10 July 2017, the Personal Data Protection Commission (the “Commission”)
received complaints from 3 individuals (the “Complainants”) alleging that when they
searched their names on the Internet, the search results included links to copies of their
360 Feedback Reports, and these reports were accessible through the links (the
“Incident”).

4

When notifying the Commission, the Complainants stated that they expected these
Reports to be private and confidential and that the disclosure of their 360 Degree
Feedback Report would have a significant impact on their job prospects and career
options. One of the Complainants alleged that as the industry the Complainant worked
in is “extremely niche”, “this could be the reason [he has] not been successful in his
job interviews over the past 2 years”. No evidence was adduced to support such claims.
Nevertheless, the possibility that the information contained in the Reports may have
been accessed by a prospective employer’s human resource personnel as they
conducted due diligence on job applications cannot be discounted.

5

The Organisation did not appear to be familiar with the security arrangements of its
Website and was not able to provide clear accounts on what led to the Incident during
the course of the investigation. In this regard, it was noted that the Organisation had
ceased the use of the Web Application in 2010, some 7 years before the Commission’s
investigation. The Organisation initially claimed that it did not know that when a client
requested for a 360 Feedback Report using the Web Application, a copy of the Report
would be saved on the Organisation’s system as a PDF file. It claimed that the Report
was dynamically generated by the Web Application and presented for viewing, without
storing a copy on the Website. However, when the operation of the Web Application
was demonstrated to it, the Organisation agreed that the Reports could have been
created but disclaimed knowledge of this. It also maintained that the data should have
been removed from the server when that particular version of the Web Application was
discontinued in 2010. In this regard, the Organisation’s explanation was that “[the Web
Application] and all its data should have been removed, but I am not sure if [the Web
Application] is still in the server”.

3

6

In relation to how the Reports became publicly accessible, the Organisation’s version
of events is that the webpages containing the Reports (the “Webpages”) were
inadvertently created on or around February 2017 during the redesign of the
Organisation’s Website. The Organisation had engaged an independent developer (the
“Developer”) to redesign its Website by changing it from HTML to WordPress. The
Developer provided a test URL to the Organisation to confirm that the Website was
designed according to the latter’s instructions. The Organisation did so, but did not
detect that the Webpages had been created. According to the Organisation, during the
redesign process, password protection for the Reports was not implemented even
though this was implemented previously. On balance, the Organisation is given the
benefit of doubt and its position that the Reports were made publicly accessible as a
result of the redesign is accepted. The complaint to the Commission (on 10 July 2017),
was submitted not long after the redesigning of the Website in or around February 2017,
and to the Commission’s knowledge, there had not been any complaints prior to this. If
the earlier version of the Website did not implement any form of access control, any
one of the employees of the Organisation’s clients who had used the system would
likely have raised this as an issue and the Organisation would have had to rectify it.

7

At the time of the Incident, the webpages contained Reports relating to 671 employees
of the Organisation’s clients (the “Affected Individuals”). Depending on the type of
Report, the information therein (collectively, “Personal Data”) may have included:
(a)

the names of the Affected Individuals;

(b)

the name and addresses of the Affected Individuals’ employers;

(c)

appraisals of the Affected Individuals’ work performance by subordinates,

supervisors and/or peers;
(d)

the Affected Individuals’ 360 Feedback scores; and

(e)

an indication of whether the Affected Individuals were top performers within

their respective organisations.

4

Remedial Measures
8

Upon being notified of the Incident by the Commission, the Organisation undertook the
following remedial actions:
(a)

moved the Reports to password-protected locations and subsequently deleted

Reports prepared for former clients;
(b)

requested the service provider hosting the Website (the “Webhost”) to provide

the Organisation with the access logs for the Webpages;
(c)

engaged a developer to scan the Website and find out whether there were more

webpages containing Reports which were accessible through the Internet without any
access restrictions; and
(d)

requested the Webhost to conduct an audit of all web based applications and

introduce enhanced security monitoring to prevent any lapses.
Findings and Basis for Determination
Whether the Organisation had breached section 24 of the PDPA
9

Section 24 of the Personal Data Protection Act 2012 (“PDPA”) requires organisations
to protect personal data in their possession or under their control by making reasonable
security arrangements to prevent unauthorised access, collection, use, disclosure,
copying, modification, disposal or similar risks. Although the Organisation had
engaged the Developer to redesign the Website, the Developer did not process any
personal data on behalf of the Organisation. The Organisation managed the Website on
its own and retained full responsibility for the IT security of the Website and the
Personal Data.

10

First, as stated in paragraph 5 above, the Organisation demonstrated a lack of
knowledge as to the security arrangements of its Website, in particular, the creation and
storage of the Reports, and had been under the mistaken impression that the Personal
Data had been removed from the server when the previous Website was discontinued.
In order to fulfil its Protection Obligation, the Organisation is required to, at the very
5

least, be aware of how and where it stores personal data in order to implement measures
to protect such data. In this regard, the Guide on Building Websites for SMEs (revised
10 July 2018) states that:
“5.7 Personal Data Inventory
5.7.1 Organisations and any engaged IT vendors should keep track of where the collected
personal data is stored, and should impose a limit on how long the data is kept, or regularly
review their need to continue storing the personal data.
5.7.2 If the personal data is no longer required, organisations and any engaged IT vendors should
then ensure that the personal data is anonymised or disposed of in such a way that it cannot be
recovered.”
[Emphasis added.]

11

Secondly, the Organisation did not give any specific instructions to the Developer to
protect personal data or on security arrangements of its Website during the redesign
process. The engagement was done over a short email exchange, and the Organisation
could not produce the contract or evidence of any written instructions to the Developer
on security arrangements. It had relied solely on the goodwill and integrity of the
Developer to conduct the redesign properly, without any documentation, supervision or
other means of control.

12

While the Organisation claimed that the Developer was engaged to merely change the
“look and feel” of the Website, the facts suggest that the redesign of the Website was a
more involved project which required a significant amount of coding work and
amounted to building a new Website. In this regard, the Developer had expressly
informed the Organisation that the scope of work involved the need to redesign the
Website on the WordPress environment instead of using the HTML coding of the
existing Website and required the existing content on the Website to be migrated. This
is not merely a redesign of the look-and-feel of the Website, but a redevelopment. Thus,
the Organisation should have provided the Developer with clear instructions to ensure
that no personal data was subject to unauthorised disclosure or access as a result of the
redesign.

6

13

According to the Guide on Building Websites for SMEs (at [4.2]):
“4.2.1 Organisations should emphasise the need for personal data protection to their IT
vendors, by making it part of their contractual terms. The contract should also state clearly the
responsibilities of the IT vendor with respect to the PDPA. When discussing the scope of the
outsourced work, organisations should consider whether the IT vendor’s scope of work will
include any of the following:


Requiring that IT vendors consider how the personal data should be handled as part
of the design and layout of the website.



Planning and developing the website in a way that ensures that it does not contain
any web application vulnerabilities that could expose the personal data of
individuals collected, stored or accessed via the website through the Internet.

…”
[Emphasis added.]

14

The Commission has also taken a similar position in Re Tutor City [2019] SGPDPC 5,
in which the organisation was unaware of its obligations under the PDPA and showed
a lack of knowledge of the security arrangements over its website. Specifically, the
organisation in that case did not, inter alia, communicate any specific security
requirements to its developer to protect the personal data stored on the website’s server
(including ensuring that the personal data would not be accessible to the public).

15

Thirdly, the Organisation failed to conduct vulnerability scans or any other form of
security testing for the Website. As set out in the Guide on Building Websites for SMEs
(at [5.6]):
“5.6 Security Testing
5.6.1 Testing the website for security vulnerabilities is an important aspect of ensuring the
security of the website. Penetration testing or vulnerability assessments should be conducted
prior to making the website accessible to the public, as well as on a periodical basis (e.g.
annually). Any discovered vulnerabilities should be reviewed and promptly fixed to prevent
data breaches.

7

5.6.2 Where organisations have outsourced the development of its website, they should either
require the IT vendor(s) to conduct the above security testing, or arrange for a cybersecurity
vendor to do so. As a baseline, organisations may wish to consider using the Open Web
Application Security Project (OWASP) Testing Guide and the OWASP Application Security
Verification Standard (ASVS) to verify that security requirements for the website have been
met.”
[Emphasis added.]

16

In Re InfoCorp Technologies Pte Ltd [2019] SGPDPC 17, the Commission took the
view that the organisation’s failure to conduct web application vulnerability scans was
a breach of section 24 of the PDPA, and that given the sensitivity of the personal data
which the documents contained, it was unreasonable that the organisation had omitted
security testing prior to the launch of the website. Also, in Re WTS Automotive Services
Pte Ltd [2018] SGPDPC 26, the Commission emphasised the need for regular review
of security arrangements and tests to detect vulnerabilities, it stated (at [18]) that:
“… [t]he Commission also recognises that personal data of individuals may be exposed if the
website or database in which it is stored contains vulnerabilities. There needs to be a regular
review to ensure that the website collecting personal data and the electronic database storing
the personal data has reasonable security arrangements to prevent unauthorised access,
collection, use, disclosure, copying, modification, disposal or similar risks. The Commission
considers that it is good practice for an organisation to “conduct regular ICT security audits,
scans and tests to detect vulnerabilities…”
[Emphasis added.]

17

In this case, even if the Organisation was unaware that the Reports were being created
and stored, had the Organisation conducted vulnerability scans as a form of security
testing on its Website prior to the redesigned Website going live or at any time after
that, the fact that the folders contained Reports with personal data and the fact that the
Reports were publicly-accessible would likely have been detected and could have been
remedied. As a result, the Organisation was unable to assess whether the folders ought
to have been restricted. It also did not consider whether any webpages which were
created as part of the redesign of its Website were correctly created.

8

18

The foregoing lapses demonstrate a fundamental lack of care by the Organisation over
the personal data in its possession and/or under its control. It is clear that the
Organisation had not applied its mind to its obligations under section 24 of the PDPA
with respect to implementing adequate security arrangements to protect the Reports. In
view of the above, the Commissioner found the Organisation in breach of section 24 of
the PDPA.

Whether the Organisation had breached sections 11(3) and 12 of the PDPA
19

Section 11(3) of the PDPA requires organisations to designate one or more individuals,
typically referred to as the data protection officer (“DPO”) to be responsible for
ensuring the organisations’ compliance with the PDPA. Section 12 of the PDPA
requires organisations to, inter alia, develop and implement policies and practices that
are necessary for the organisation to meet its obligations under the PDPA (“Data
Protection Policies”), and to communicate information about such policies and
practices to its staff.

20

In the course of the Commission’s investigations, the Organisation admitted that it was
unaware of the data protection provisions of the PDPA and was under the impression
that the PDPA only relates to the Do-Not-Call provisions. Hence, the Organisation did
not appoint a DPO or develop and implement any Data Protection Policies. In this
regard, it is a trite principle of law that ignorance of the law is no excuse. Hence, the
Organisation’s lack of awareness of its obligations under the PDPA is not an excuse for
contravening the PDPA.

21

The Organisation also admitted that, at the time of the Incident, it only had certain
unwritten policies with respect to the protection of client data, which were
communicated to its employees. In this regard, it is important to reiterate that an
organisation’s Data Protection Policies should be documented in a written policy, as
per Re Furnituremart.sg [2017] SGPDPC 7 at [14]:
“[t]he lack of a written policy is a big drawback to the protection of personal data. Without
having a policy in writing, employees and staff would not have a reference for the
Organisation’s policies and practices which they are to follow in order to protect personal data.
Such policies and practices would be ineffective if passed on by word of mouth, and indeed, the

9

Organisation may run the risk of the policies and practices being passed on incorrectly. Having
a written policy is conducive to the conduct of internal training, which is a necessary component
of an internal data protection programme.”

22

In light of the foregoing, the Commissioner found that the Organisation had also
breached sections 11(3) and 12 of the PDPA.

Representations by the Organisation

23

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

amount of financial penalty that was to be imposed. The Organisation raised the following
factors for consideration:
(a)

The Commission should not have placed such significant weight on the Personal

Data in the Reports that was exposed in the Incident. In this regard, the Personal Data
in the Reports should not be accorded the status of sensitive personal data and treated
as an aggravating factor because:
(i)

The

Reports

did

not

contain

the

Affected

Individual’s

identification/NRIC number, health data or biometric data. The identifying
personal data was limited to the name of the Affected Individuals and the name
of his/her employer; and
(ii)

The feedback data in the Reports would not fall within the realm of what

would typically be known as sensitive personal data as defined in Articles 9 and
10 of the European General Data Protection Regulation (“GDPR”);
(b)

Any aggravating weight to be given to the disclosure of the Reports must be

reduced by the fact that evaluative purpose exception in the PDPA permits a prospective
employer to obtain such feedback or evaluative information without consent of the
Affected Individuals. The Organisation posited that the evaluative purpose exception
tempers the extent of breach or application of the Protection Obligation because
disclosure is permitted so long as the exception applies;
(c)

The possibility of a member of the public specifically carrying out keyword

searches of the names of Affected Individuals during the period when the specific URL
links leading to the Reports had been exposed would not be high;
10

(d)

The Reports were not more recent than the year 2010. As the Incident occurred

in 2017, the accuracy of the contents of the Reports would have waned with the
effluxion of time, and this could be a point taken into consideration by a prospective
employer;
(e)

In past decisions, the Commission has taken into consideration the financial

circumstances of an organisation in determining the financial penalty (if any) to be
imposed. The financial penalty that the Commissioner intended to impose would have
a crushing burden on the Organisation, and cause undue hardship. Further, taking into
consideration the type of personal data and the potential harm to the Affected
Individuals, the proposed financial penalty would be disproportionately higher than
what had been imposed on organisations in previous decisions; and
(f)

The Incident was a one-off occurrence and there was no evidence that the

Website was otherwise insecure. During the past 16 over years that the Organisation
has been in business, there were no other complaints in relation to unauthorised
disclosure of personal data.
24

With respect to the Organisation’s representations on the nature of the Personal Data in
the Reports at [23(a)], Singapore’s legislative approach to determining the sensitivity
of personal data is different from jurisdictions like the European Union. Unlike the
GDPR, the PDPA does not have a definition of sensitive personal data. It is
inappropriate to draw comparisons with the GDPR approach to defining sensitivity of
personal data as the jurisprudential basis of GDPR is markedly different from the PDPA.
The Commission’s approach in each case is to assess the nature of the personal data in
question, taking into account specific circumstances such as the context in which the
data was collected and the potential risk of harm due to unauthorised access or
disclosure.

25

The Organisation’s representations on the evaluative purpose exception at [23(b)]
cannot be accepted. The fact that personal data that may be collected, used or disclosed
under an exception to consent cannot ipso facto be equated with an inference that the
class of personal data is less sensitive and need not be protected, or that there is less
culpability for a failure to protect. It is necessary to examine the nature of the exception
and the raison d’etre for its existence. The following analysis is confined to the
11

evaluative purpose and is not intended to establish any special rule for personal data
covered by other exceptions.
(a)

The PDPA recognises that there is a class of personal data that exists for an

evaluative purpose. A perusal of its definition discloses that the categories of activities
are characterised by the need for full disclosure and frank discussions in order to arrive
at a decision to, for example, employ, promote or dismiss a person, amongst a list of
other circumstances that circumscribe this purpose.1 The recognition of the need for
full disclosure and frank discussions is carried through in a number of exceptions,
which permit personal data to be collected, used and disclosed without consent. 2
Further, personal data in the nature of opinion data kept solely for an evaluative purpose
is exempted from the access and correction requirements. 3 The upshot of these
exceptions is to recognise the necessity to preserve the space for full disclosure of
relevant personal data and frank exchanges of views between persons who are tasked
to conduct an evaluation before making a decision or recommendations leading to a
decision.
(b)

Given the nature of the evaluative purpose exceptions and their raison d’etre, it

is necessary to ensure that organisations accord personal data that is covered by the
evaluative purpose exceptions with a higher degree of protection. The quid pro quo for
organisations having the liberty to collect, use and disclose personal data without
consent for evaluative purposes, and to keep opinion data beyond the reach of data
subjects for access and correction, is that they are expected to put in place more robust
measures to comply with the Protection Obligation. In other words, personal data that
is kept for an evaluative purpose should be treated as sensitive data and be protected to
a greater degree.

See definition of “evaluative purpose” in section 2 of the PDPA. See also Section 29(3) of New Zealand’s
Privacy Act 1993 which has a similar definition of “evaluative material” for the purposes of a refusal to disclose
personal information pursuant to Principle 6 (Access to personal information).
2
See para 1(f) of the Second Schedule, para 1(f) of the Third Schedule and para 1(h) of the Fourth Schedule of
the PDPA.
3
See para 1(a) of the Fifth Schedule and para 1(a) of the Sixth Schedule of the PDPA respectively. See also
Section 29(1)(b) of New Zealand’s Privacy Act 1993 which permits an agency to refuse to disclose personal
information pursuant to Principle 6 if (i) the disclosure of the information or of information identifying the
person who supplied it, being evaluative material, would breach an express or implied promise (i) which was
made to the person who supplied the information; and (ii) which was to the effect that the information or the
identity of the person who supplied it or both would be held in confidence.
1

12

(c)

Further, the Incident in the present case involved the risk of unauthorised

disclosure to the world at large whereas the evaluative purpose exception is much
narrower in scope (i.e. it permits disclosure of personal data without consent to specific
individual(s)/organisation(s) only where it is necessary for evaluative purposes). The
expectations of persons who provided the 360-degree feedback would have been for
their feedback to be accessed by persons with a role in evaluating the performance of
the employee under review. It would be difficult, by any stretch of imagination, for
them to accept that their feedback was accessible by the world at large.
26

The possibility of actual unauthorised disclosure raised by the Organisation at [23(c)]
had already been taken into consideration in determining the financial penalty that was
to be imposed. While the risk of actual unauthorised disclosure may have not been high,
the fact that the Reports were exposed to the risk of unauthorised access and disclosure
for more than 7 years (between 2009 to 2017) is particularly glaring.

27

As for the accuracy of the contents of the Reports at [23(d)], the passage of
approximately 7 years is unlikely to make a significant difference to the potential harm
suffered by the Affected Individuals due to unauthorised access or disclosure of the
Reports, or dampen the expectations of the persons who provided feedback as discussed
in [25(c)].

28

With respect to the Organisation’s representations comparing the present case to earlier
decisions at [23(e)], it needs only be said that each decision is based on the unique facts
of that case. The decision in each case takes into consideration the specific facts of the
case so as to ensure that the decision and direction(s) are fair and appropriate for that
particular organisation.

29

The fact that the Incident may have been the Organisation’s first data breach is not a
mitigating factor. Conversely, if the Incident was a repeated contravention by the
Organisation of the Protection Obligation, this would likely weigh in favour of a higher
financial penalty.

30

Having carefully considered the representations, the Commissioner has decided to
reduce the financial penalty to the amount set out at [33(a)]. The quantum of financial
penalty has been determined after due consideration of the appropriate weight to be
13

given to the aggravating factors at [32], the Organisation’s financial circumstances and
to avoid imposing a crushing burden on the Organisation. Although a lower financial
penalty has been imposed in this case, this is exceptional and should not be taken as
setting any precedent for future cases.
The Commissioner’s Directions
31

In determining the directions to be imposed on the Organisation under section 29 of the
PDPA, the Commissioner took into account, as a mitigating factor, the fact that the
Organisation had promptly taken the remedial measures set out above (at [8]).

32

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

the Personal Data in the Reports were sensitive in nature as they included data

on the assessment of the Affected Individuals’ work performance and unauthorised
access of such data could potentially result in harm to the individuals concerned (for
example, the individuals’ future employment prospects may be affected);
(b)

the Personal Data in the Reports was exposed to the risk of unauthorised access

and disclosure for a period of more than 7 years; and
(c)

the Organisation showed a lack of awareness of its obligations under the PDPA

even though it processes large volumes of sensitive personal data in the course of its
business.
33

Having carefully considered the facts and circumstances of this case and the above
mitigating and aggravating, the Commissioner hereby directs the Organisation:
(a)

To pay a financial penalty of $90,000 within 30 days of the date of this direction,

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

to appoint a DPO within 30 days from the date of this direction; and

14

(c)

to develop and implement policies and practices that are necessary for the

Organisation to meet its obligations under the PDPA, and communicate them to its
staff, within 30 days of the date of this direction.

YEONG ZEE KIN
DEPUTY COMMISSIONER
FOR COMMISSIONER FOR PERSONAL DATA PROTECTION

15

",Financial Penalty,6a21009555c09878fe1f590900953bc8f01d5acf,"[""pdf-content"",""timestamp"",""decision"",""pdf-url"",""tags"",""nature"",""url"",""title"",""date"",""description""]"
2023-10-01T11:02:10+08:00,fbd32491db44d3d0c97aa12a99cefd61ec954264,76,76,1,952,"Directions were imposed on Everlast Projects, Everlast Industries (S) and ELG Specialist for breaches of the PDPA. First, the organisations failed to put in place reasonable measures to protect their employees’ personal data. Second, they did not have written policies and practices necessary to ensure its compliance with the PDPA.","[""Accountability"", ""Protection"", ""Directions"", ""Construction"", ""No Policy"", ""Ransomware""]",2020-12-18,https://www.pdpc.gov.sg/-/media/Files/PDPC/PDF-Files/Commissions-Decisions/Decision---Everlast-Projects-and-Others---301020.pdf,"Accountability, Protection","Breach of the Accountability and Protection Obligations by Everlast Projects, Everlast Industries (S) and ELG Specialist",https://www.pdpc.gov.sg/all-commissions-decisions/2020/12/breach-of-the-accountability-and-protection-obligations-by-everlast-projects,2020-12-18,"PERSONAL DATA PROTECTION COMMISSION

[2020] SGPDPC 20

Case No. DP-1908-B4369

In the matter of an investigation under section 50(1)
of the Personal Data Protection Act 2012
And
(1) Everlast Projects Pte Ltd
(2) Everlast Industries (S) Pte Ltd
(3) ELG Specialist Pte Ltd
… Organisations

DECISION

Everlast Projects Pte Ltd & Others

[2020] SGPDPC 20

Everlast Projects Pte Ltd & Others
[2020] SGPDPC 20

Yeong Zee Kin, Deputy Commissioner — Case No. DP-1908-B4369
30 October 2020

Introduction
1

On 29 September 2019, Everlast Projects Pte Ltd (“EPPL”) notified the

Personal Data Protection Commission (“Commission”) that its server (“Server”) had
been hacked and all the files within it were encrypted by ransomware sometime in
August 2019 (the “Incident”).
Facts of the Case
2

EPPL, Everlast Industries (S) Pte Ltd (“EIPL”) and ELG Specialist Pte Ltd

(“ESPL”) (collectively, the “Organisations”) specialise in the supply and installation of
architectural metal works, glass and aluminium products. The Organisations are
owned by the same shareholder, managed by the same directors, and operate from
common premises. Two of the Organisations also have a common name, “Everlast”.
The Organisations operated like a group of companies and centralised their payroll
processing, such that the human resources (“HR”) department of EPPL was in charge
of processing payrolls of not only its own employees, but also the employees of EIPL
and ESPL. The Organisations’ employees’ personal data were stored in the Server,
which was owned and maintained by EPPL.
3

On 10 August 2019, EPPL discovered the Incident. EPPL had both an onsite

physical backup and a secondary cloud backup of the contents of the Server. The
physical backup was affected by the ransomware and rendered unusable. A total of
384 individuals were affected by the Incident (the “Affected Employees”):
2

Everlast Projects Pte Ltd & Others

[2020] SGPDPC 20

Name of Organisation

Number of employees affected

EPPL

141

EIPL

239

ESPL

4

Total number of individuals

384

4

The types of personal data of the Affected Employees that were at risk of

unauthorised access included the following (collectively, the “Personal Data Sets”):
(a)

Name;

(b)

NRIC/FIN number;

(c)

Date of birth;

(d)

Bank account details; and

(e)

Information relating to salary.

5

The cause of the ransomware infection was not identified. EPPL’s

investigations could not determine how the ransomware gained entry to the Server.
EPPL was also unable to confirm whether any of the Personal Data Sets had been
exfiltrated as a result of the Incident. Upon discovery of the Incident, EPPL took prompt
remedial action by ceasing to use the Server immediately.
6

Findings and Basis for Determination

7

The two issues to be determined in this case are as follows:
(a)

Whether the Organisations had each complied with their obligations under
section 12 of the Personal Data Protection Act 2012 (the “PDPA”); and

(b)

Whether the Organisations had each complied with their obligations under
section 24 of the PDPA.
3

Everlast Projects Pte Ltd & Others

[2020] SGPDPC 20

Whether EPPL, EIPL and ESPL had each complied with their obligations under section
12 of the PDPA
8

Section 12 of the PDPA requires organisations to, inter alia, develop and

implement policies and practices that are necessary for the organisation to meet its
obligations under the PDPA, and to communicate information about such policies and
practices to its staff (the “Accountability Obligation”).
9

In this regard, it is important to reiterate that an organisation’s Data Protection

Policies should be documented in a written policy, as per Re Furnituremart.sg [2017]
SGPDPC 7 at [14]:
“[t]he lack of a written policy is a big drawback to the protection of personal data. Without having
a policy in writing, employees and staff would not have a reference for the Organisation’s policies
and practices which they are to follow in order to protect personal data. Such policies and
practices would be ineffective if passed on by word of mouth, and indeed, the Organisation may
run the risk of the policies and practices being passed on incorrectly. Having a written policy is
conducive to the conduct of internal training, which is a necessary component of an internal data
protection programme.”

10

As mentioned at [2], EPPL, EIPL and ESPL operated as a group of companies

in the sharing of payroll processing services, which are centralised within the HR
department of EPPL. The Commission recognises the commercial benefits which arise
from centralising common corporate functions within a group of companies. In such
situations, one entity (the “Servicing Organisation”) provides corporate services to
other entities in the same corporate group (each a “Contracting Organisation”). If
the shared common corporate services involve the processing of personal data, the
Servicing Organisation would be acting as a data intermediary for each Contracting
Organisation.1
11

The common corporate service shared by the Organisations in the present case

was the payroll processing function. EIPL and ESPL were therefore permitted to
collect, without consent, their respective Affected Employees’ Personal Data Sets and

1

See the Commission’s Advisory Guidelines on Key Concepts in the PDPA (revised 2 June 2020) at [6.28].

4

Everlast Projects Pte Ltd & Others

[2020] SGPDPC 20

disclose the same to EPPL for the purposes of managing the employment
relationship.2 In these circumstances, EPPL was:
(a)

A data controller with respect to its own Affected Employees’ Personal

Data Sets; and
(b)

EIPL and ESPL’s data intermediary with respect to their respective

Affected Employees’ Personal Data Sets that EPPL was processing on their
behalf.
12

The Organisations admitted that they did not have any written data protection

policies and relied only on verbal instructions to employees. Although the
Organisations are in the construction industry and, in this case, do not typically collect
personal data from customers, the Accountability Obligation required the
Organisations to put in place data protection policies in relation to the protection of
personal data of their respective employees.
13

In this regard, organisations operating as a group of companies may comply

with the Accountability Obligation through binding group-level written policies or intragroup agreements that set out a common and binding standard for the protection of
personal data across all organisations in the same corporate group. These binding
group-level written policies or intra-group agreements are akin to binding corporate
rules (“BCRs”) imposed by an organisation on its overseas recipient of the personal
data (in compliance with the Transfer Limitation Obligation under Section 26(1) of the
PDPA), which oblige the overseas recipient to provide a standard of protection to the
transferred personal data that is at least comparable to that under the PDPA. 3 Where
the corporate group is a multinational corporation (“MNC”) and the Contracting
Organisation transfers personal data to an overseas Servicing Organisation, the
binding group-level written policies, intra-group agreements or BCRs which meet the

2

See Second Schedule of the PDPA, para 1(o) and Fourth Schedule of the PDPA, para 1(s).
The Transfer Limitation Obligation under Section 26 of the PDPA requires an organisation that transfers
personal data to a country or territory outside of Singapore to take appropriate steps to ensure that the
recipient of personal data is bound by legally enforceable obligations to provide to the transferred personal
data a standard of protection that is at least comparable to that under the PDPA.
3

5

Everlast Projects Pte Ltd & Others

[2020] SGPDPC 20

requirements of the Protection Obligation under section 24 of the PDPA4 would also
meet the requirements of section 26(1) of the PDPA in relation to the Protection
Obligation.5
14

In the present case, the Organisations did not have any such binding group-

level written policies, intra-group agreements or BCRs. In the circumstances, I find
each of EPPL, EIPL and ESPL in breach of the Accountability Obligation.
Whether EPPL, EIPL and ESPL had contravened section 24 of the PDPA
15

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

possession or under its control by making reasonable security arrangements to
prevent unauthorised access, collection, use, disclosure, copying, modification or
similar risks (the “Protection Obligation”). The obligation to make reasonable security
arrangements does not attach unless the organisation is in possession or control of
personal data.
16

As mentioned at [10], EPPL was (i) a data controller with respect to its own

Affected Employees’ Personal Data Sets; and (ii) EIPL and ESPL’s data intermediary
with respect to their Affected Employees’ Personal Data Sets that EPPL was
processing on their behalf. In this regard, EPPL, EIPL and ESPL had possession
and/or control of the Affected Employees’ Personal Data Sets at the material time.
(a)

EPPL was in possession and control of the Affected Employees’ Personal Data
Sets. This was because the Organisations’ payroll processing functions were
centralised within the HR department of EPPL.

(b)

While EIPL and ESPL did not have possession of their respective Affected
Employees’ Personal Data Sets because they were centrally hosted on EPPL’s
Server, I find that EIPL and ESPL remained in control of their respective Affected
Employees’ Personal Data Sets as data controllers. This is because the

4
5

The Protection Obligation is explained at paragraph 14.
See, for illustration, Re Cigna Europe Insurance Company S.A.-N.V. [2019] SGPDPC 18 at [13].

6

Everlast Projects Pte Ltd & Others

[2020] SGPDPC 20

processing of EIPL’s and ESPL’s Affected Employees Personal Data Sets by
EPPL was for EIPL’s and ESPL’s respective business purposes.6
17

Each of the Organisations were therefore obliged to put in place reasonable

security arrangements to protect the Affected Employees Personal Data Sets,
including preventing the risk of unauthorised modification. In the present case, the
Commission’s investigations into the Incident revealed that the ransomware had
encrypted all the files in the Server and its physical backup, including the Affected
Employees’ Personal Data Sets. The unauthorised modification of the Affected
Employees’ Personal Data Sets by the ransomware made it unreadable and unusable.
18

It is well established that a data controller should have in place a written contract

with its data intermediary that clearly specifies the data intermediaries’ obligation to
protect personal data. 7 That said, the relationship between the Organisations is a
relevant factor in determining the reasonable security measures expected of them to
comply with the Protection Obligation. In this regard, for a group of companies, the
written contract requirement between a Servicing Organisation and the Contracting
Organisation may be met by binding group-level written policies, intra-group
agreements or BCRs as discussed at [13] above.
19

In addition to a written agreement specifying data protection requirements, a

Contracting Organisation should also implement operational processes so as to be
able to exercise some form of supervision or control over the activities of the Servicing
Organisation when it processes personal data on the Contracting Organisation’s
behalf.8 Where the Servicing Organisation has specialised knowledge, skills and/or
tools for processing personal data, having a robust audit framework could be an
appropriate form of oversight. This may be particularly suited for MNCs which typically

6

See Re The Cellar Door Pte Ltd and another [2016] SGPDPC 22 at [17] – [18]; Re AIG Asia Pacific Insurance Pte
Ltd [2018] SGPDPC 8 at [18].
7

See the Commission’s Guide on Data Protection Clauses for Agreements relating to the Processing of Personal
Data (20 July 2016) at [4]; Re Singapore Telecommunications Limited [2017] PDPC 4 at [14]
8
The Commission’s Advisory Guidelines on Key Concepts in the PDPA (revised 2 June 2020) at [17.5] provides
that “[e]nsuring that IT service providers are able to provide the requisite standard of IT security” is an
example of a technical measure an organisation may use to protect personal data.

7

Everlast Projects Pte Ltd & Others

[2020] SGPDPC 20

conduct periodic internal and/or external audits and assessments to monitor
compliance by each organisation within the corporate group.9 Conversely, small and
medium-sized enterprises that only operate in Singapore are less likely to conduct
such compliance audits on each organisation in the corporate group in the areas of
cybersecurity and/or data protection. In such situations, appropriate oversight could
involve more simple processes. For example, requiring the Servicing Organisation to
explain to the Contracting Organisation the measures which would be taken to secure
personal data, with appropriate documentation to evidence this process (e.g. written
acknowledgement given by the Contracting Organisation to the Servicing
Organisation), and provide regular reports showing that it has put these processes in
place.
20

In the present case, both EIPL and ESPL failed to put in place reasonable

security arrangements to ensure that EPPL (who was their data intermediary for the
purposes of payroll processing) would protect their respective Affected Employees’
Personal Data Sets. There was no written contract, intra-group agreement or grouplevel written policies/BCRs setting out data protection requirements that EPPL was
obliged to comply with when processing EIPL’s and ESPL’s respective Affected
Employees’ Personal Data Sets. Notwithstanding that the Organisations conducted
their business operations from the same premises, both EIPL and ESPL also did not
implement any operational processes to supervise or exercise some form control over
EPPL to ensure EPPL protected their Affected Employees’ Personal Data Sets. In the
circumstances, I find each of EIPL and ESPL in breach of the Protection Obligation.
21

EPPL was also obliged to comply with the Protection Obligation. As mentioned

in [10], it was: (i) a data controller with respect to its own Affected Employees’ Personal
Data Sets; and (ii) EIPL and ESPL’s data intermediary with respect to their Affected
Employees’ Personal Data Sets. The Commission’s Investigations revealed that EPPL
did not put in place reasonable security arrangements to protect the Personal Data
Sets as explained below:

9

As an example, see Re Cigna Europe Insurance Company S.A.-N.V. [2019] SGPDPC 18 at [7(c)].

8

Everlast Projects Pte Ltd & Others

(a)

[2020] SGPDPC 20

EPPL did not install a firewall for the Server. Without a firewall, the Server and
corporate network was vulnerable to web-based security threats;10

(b)

EPPL did not conduct periodic security reviews of its IT systems, including
vulnerability scans of the Server, to assess the overall security of its IT
infrastructure. The requirement for organisations to conduct periodic security
reviews of its IT systems has been emphasized in previous decisions. 11
Conducting regular information and communication technology (“ICT”) security
audits, scans and tests to detect vulnerabilities help organisations to ensure
that ICT security controls developed and configured for the protection of
personal data are properly implemented. 12 The comprehensiveness of such
security reviews should be scoped based on the organisation’s assessment of
its data protection needs, and be conducted to a reasonable standard. The
scope and level of the review would depend on the type of personal data to be
protected. In this case, as the Personal Data Sets included personal data of a
financial nature (e.g. information relating to bank accounts and salaries), a
higher standard of periodic security review was required of EPPL in order to
comply with the Protection Obligation. If EPPL had conducted a security review
of its IT system to a reasonable standard, it would have discovered the absence
of a firewall for the Server; and

(c)

EPPL was unable to provide any written IT security policies (e.g. password
policy, policies for patching and updating of the company server, etc.). 13 In this
regard, EPPL conceded that they did not know what was required in order to
protect personal data in electronic form.

10

The Commission’s Guide to Securing Personal Data in Electronic Medium (20 January 2017) at [9.1] states as
follows: “It is important for an organisation to ensure that its corporate computer networks are secure.
Vulnerabilities in the network may allow cyber intrusion, which may lead to theft or unauthorised use of
electronic personal data. Defences that may be used to improve the security of networks include: […]
Firewalls”.
11
See, for example, Re WTS Automotive Services Pte. Ltd. [2018] SGPDPC 26 at [18], Re Bud Cosmetics [2019]
SGPDPC 1 at [24] and Re Chizzle Pte. Ltd. [2019] SGPDPC 44 at [6] to [8].
12
Commission’s Guide to Securing Personal Data in Electronic Medium (revised 20 January 2017) at [6.1].
13
The Commission’s Advisory Guidelines on Key Concepts in the PDPA (revised 2 June 2020) at [17.5] provides
that “[s]ecurity arrangements may take various forms such as administrative measures, physical measures,
technical measures or a combination of these”. Having robust policies and procedures is an example of an
administrative measure an organisation may implement by way of security arrangements.

9

Everlast Projects Pte Ltd & Others

22

[2020] SGPDPC 20

For the reasons above, I also find EPPL in breach of the Protection Obligation.

Directions
23

In determining the directions, if any, to be imposed on EPPL, EIPL and ESPL

under section 29 of the PDPA, I took into account the following factors:
(a)

The Organisations had voluntarily notified the Commission of the Incident;

(b)

The Commission did not receive any complaints of the Personal Data Sets being
disclosed online or otherwise misused;

(c)

There was no evidence of exfiltration of the Personal Data Sets; and

(d)

An imposition of a financial penalty would impose a crippling burden and cause
undue financial hardship due to the financial position of the Organisations.

24

Having considered all the relevant factors of this case, I direct EPPL, EIPL and

ESPL to:
(a)

Develop and implement intra-group agreements or binding corporate

rules that set out a common and binding standard for the processing of personal
data when centralising common corporate activities within the group, within 90
days from the date of this direction;
(b)

Review and ensure that the internal policies within each of EPPL, EIPL

and ESPL are in line with the standards set forth in the intra-group agreements
or binding corporate rules, within 90 days from the date of this direction; and
(c)

Inform the Commission of the completion of the directions set out at

[23(a)] and [23(b)] within one week.

YEONG ZEE KIN
DEPUTY COMMISSIONER
FOR PERSONAL DATA PROTECTION
10

",Directions,6bf33286d1c3d26557836242297e0273d9b08921,"[""pdf-content"",""timestamp"",""decision"",""pdf-url"",""tags"",""nature"",""url"",""title"",""date"",""description""]"
2023-10-01T11:02:10+08:00,fbd32491db44d3d0c97aa12a99cefd61ec954264,155,155,1,952,"A financial penalty of $33,000 was imposed on DS Human Resource for breaches of the PDPA. The organisation failed to put in place data protection policies.  It also did not make reasonable security arrangements to prevent the unauthorised disclosure of the personal data of job applicants.","[""Accountability"", ""Protection"", ""Financial Penalty"", ""Employment"", ""Accommodation and F&B"", ""HR"", ""Jobs""]",2019-06-13,https://www.pdpc.gov.sg/-/media/Files/PDPC/PDF-Files/Commissions-Decisions/Grounds-of-Decision---DS-Human-Resource---130619.pdf,"Accountability, Protection",Breach of the Openness and Protection Obligations by DS Human Resource,https://www.pdpc.gov.sg/all-commissions-decisions/2019/06/breach-of-the-openness-and-protection-obligations-by-ds-human-resource,2019-06-13,"PERSONAL DATA PROTECTION COMMISSION

[2019] SGPDPC 16
Case No DP-1802-B1756

In the matter of an investigation under section 50(1)
of the Personal Data Protection Act 2012
And
DS Human Resource Pte. Ltd.
… Organisation

DECISION

DS Human Resource Pte. Ltd.
[2019] SGPDPC 16
Tan Kiat How, Commissioner — Case No DP-1802-B1756

13 June 2019.
Background
1

Open source software is increasing in popularity and prevalence. This

case illustrates the risks to companies in using default settings of open source
software without any assessment of the security features. On 25 February 2018,
DS Human Resource Pte. Ltd. (“DSHR”) informed the Personal Data
Protection Commission (the “Commission”) of a data breach involving
unauthorised access and deletion of its database by a hacker. Following an
investigation into the matter, the Commissioner found DSHR in breach of
sections 12 and 24 of Personal Data Protection Act 2012 (“PDPA”).
Material Facts
2

DSHR specialises in the outsourcing of part-time staff to the food and

beverage industry in Singapore. Individuals interested in applying for a parttime job would enter their personal data into DSHR’s mobile application. The
personal data collected by DSHR’s mobile application was stored on MongoDB
database, an open source database software used by DSHR since April 2017
(“Database”).

DS Human Resource Pte. Ltd.

3

[2019] SGPDPC 16

The Database is hosted on Amazon Web Services (“AWS”) server. The

source code used by DSHR to perform specific functions on the Database was
stored in Github, an online code repository. The administration of DSHR’s
Database was handled mainly by DSHR’s director. At the material time, the
Database stored personal data of approximately 2,100 individuals, including:
(a)

Name;

(b)

NRIC Number;

(c)

Date of Birth;

(d)

Gender;

(e)

Emergency Contact;

(f)

Bank Account Details;

(g)

Work Experience;

(h)

Educational Qualification; and

(i)

Image of front and back of NRIC.

(collectively, “DSHR’s Data”)
4

On 24 February 2018, DSHR discovered unauthorised access to the

Database and deletion of DSHR’s Data. The hacker demanded payment of 0.25
bitcoins in exchange for restoring the Database. Notwithstanding DSHR’s
payment on the same day, the hacker did not restore the Database (collectively,
the “Incident”). DSHR did not have a backup and was unable to recover the
deleted DSHR’s Data.

2

DS Human Resource Pte. Ltd.

5

[2019] SGPDPC 16

DSHR took the following remedial actions after the Incident:
(a)

Changed all of the passwords of its AWS account;

(b)

Restricted connections to DSHR’s AWS server to DSHR’s IP

addresses only;
(c)

Disabled remote access to the MongoDB server software;

(d)

Engaged consultants to perform vulnerability and penetration

testing, and remedied the issues found in the tests, such as an issue
concerning session management;
(e)

Installed HTTPS at www.dshradmin.com;

(f)

Changed the username of it AWS account; and

(g)

Notified all affected individuals via SMS.

The Commissioner’s Findings and Basis for Determination
6

It is not disputed that the DSHR’s Data is “personal data” as defined in

section 2(1) of the PDPA. There is also no dispute that the PDPA applies to
DSHR as it falls within PDPA’s definition of “organisation”.
7

The issues to be determined by the Commissioner in this case are as

follows:
(a)

Whether DSHR had complied with its obligations under Section

24 of the PDPA; and
(b)

Whether DSHR had complied with its obligations under Section

12 of the PDPA.

3

DS Human Resource Pte. Ltd.

[2019] SGPDPC 16

Whether DSHR complied with its obligations under section 24 of the PDPA
8

Section 24 of the PDPA provides that an organisation shall protect

personal data in its possession or under its control by making reasonable
security arrangements to prevent unauthorised access, collection, use,
disclosure, copying, modification, disposal or similar risks. It is not disputed
that DSHR had possession and control of DSHR’s Data stored in the Database,
and hosted on the AWS Server.
9

The investigations found that DSHR failed to put in place reasonable

security arrangements to protect the DSHR’s Data for the following reasons:
(a)

The default settings of the MongoDB open source database

software allowed remote connections through the internet. By using the
default settings, DSHR’s Data stored on the Database was exposed.
DSHR used the default settings without any assessment of whether this
was a reasonable security arrangement to protect DSHR’s Data stored
on the Database. In this regard, DSHR admitted that it focused on the
installation and functional use of the MongoDB database software rather
than its security.
(b)

There was readily available information and documents on

security of the MongoDB software (e.g. steps to take to enable access
control and limit network exposure). This included MongoDB’s blog
post on 6 January 2017 referring to a Security Manual and Checklist
which DSHR should have referred to when installing the MongoDB
software in April 2017. DSHR failed to do so. As highlighted in the
Commission’s Guide to Securing Personal Data in Electronic Medium,
organisations need to put in place adequate protection for databases that

4

DS Human Resource Pte. Ltd.

[2019] SGPDPC 16

contain personal data, and consider their security requirements when
selecting a database product.1
(c)

DSHR’s Data included bank account details which is personal

data of a sensitive nature.2 As highlighted in Re Credit Counselling
Singapore [2017] SGPDPC 18 at [25], when it comes to the protection
of sensitive personal data, there is a need to put in place stronger security
measures because of the actual or potential harm, and the severity of
such harm, that may befall an individual from a misuse or unauthorised
use of such data. In the circumstances, it was completely inexcusable for
DSHR to use the default settings in the MongoDB open source database
software without addressing its mind to the questions whether remote
access to DSHR’s Data was necessary and, if not, ensuring that the
remote access functionality of MongoDB was disabled.
(d)

More fundamentally, MongoDB did not have an administrator

password by default. It is necessary for all organisations making use of
IT solutions to secure the administrator account by changing its default
password to something unique and not easily guessable.
(e)

The Commissioner finds that DSHR failed to put in place any

security or access controls to the Database (e.g. through password
protection), resulting in DSHR’s Data being exposed to the Internet.
This case is analogous to the case Re Propnex Realty Pte Ltd [2017]
SGPDPC 1, where it was found that the organisation failed to properly
protect personal data as it did not have any security controls or

1

PDPC, Guide to Securing Personal Data in Electronic Medium at [13.1]-[13.2].

2

Re AIA Singapore Pte Ltd [2016] SGPDPC 10 at [19].

5

DS Human Resource Pte. Ltd.

[2019] SGPDPC 16

restrictions (i.e. proper authentication system) to prevent access from the
Internet over the webpages that were stored on the server.
10

The investigations also revealed that DSHR had inadequate patch

management processes. At the material time, notwithstanding GitHub had
published documentation on its website advising periodic manual review by
users, DSHR relied completely on GitHub for MongoDB patch alerts. GitHub
is a portal for collaborative storage and management of source code in the
developer community. Its features include providing security alerts of common
vulnerabilities. However, it is not a complete substitute for monitoring IT
security portals (eg Common Vulnerabilities and Exposures system, or CVE)
and the security and patch information feed direct from the software solution
provider (ie MongoDB). DSHR ought to have actively monitored for new
patches released for software components and from the correct sources. Cyber
attackers are well aware of vulnerabilities available for exploiting. It is
important for organisations to keep their software updated or patched regularly
to minimise their vulnerabilities.3
Whether DSHR complied with its obligations under section 12 of the PDPA
11

DSHR admitted that it did not have any policies or internal guidelines

which specify the rules and procedures on the collection, use and disclosure of
personal data. DSHR’s omission to do so and consequential failure to
communicate such policies and internal guidelines to its employees amounts to
a breach of section 12 of the PDPA.

3

PDPC, Guide to Securing Personal Data in Electronic Medium at [16.3]-[16.4].

6

DS Human Resource Pte. Ltd.

[2019] SGPDPC 16

Representations by DSHR
12

In the course of settling this decision, DHSR made representations on

the amount of financial penalty which the Commissioner intended to impose,
while agreeing with the Commissioner’s findings and basis of determination set
out above.
13

In its representations on the amount of financial penalty, DSHR

requested that the Commissioner consider the following factors:
(a)

DSHR asserted that the Incident arose due to its director’s

negligence but hopes that the director’s lack of technical knowledge may
be taken into account;
(b)

The popularity of MongoDB database software and the fact that

it was used by many big companies worldwide led DSHR’s director to
believe that the database would have reasonable security reliability; and
(c)

DSHR’s determination to proceed with automation of its

business processes notwithstanding difficulties faced, including hiring a
full time developer moving forward;
14

Having considered representations, the Commissioner acknowledges

DSHR’s determination to automate its business processes and its director’s
initiative to do so in response to the Government’s push for small and medium
enterprises (“SMEs”) go digital, particularly when difficulties in hiring
technically skilled staff would have discouraged others. The Commissioner
would like to take this opportunity to highlight that good data management and
protection practices need to be adopted from the onset of the digitalisation
process, and these can be proportionate without being too costly. SMEs are

7

DS Human Resource Pte. Ltd.

[2019] SGPDPC 16

urged to tap on available Government funding and support programmes to assist
SMEs in their digitalisation efforts.
15

The Commissioner has decided to maintain the financial penalty set out

in paragraph 19 for the following reasons:
(a)

An organisation’s lack of technical knowledge cannot be a

mitigating factor. As explained in WTS Automotive Services Pte Ltd
[2018] SGPDPC 26 at [24], the responsibilities of ownership do not
require technical expertise. In this regard, if an organisation does not
have the requisite level of technical expertise to manage its IT system,
the organisation may either procure technical expertise internally (e.g.
by training its existing employees or hiring individuals with relevant
expertise) or engage competent service providers and give proper
instructions; and
(b)

The security features or reliability of the MongoDB database

software were not the issue. It was DSHR’s failure to ensure that the
appropriate security settings were configured to protect DSHR’s Data.
This is therefore not a mitigating factor.
The Commissioner’s Directions
16

Given the Commissioner’s findings that DSHR is in breach of sections

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

8

DS Human Resource Pte. Ltd.

17

[2019] SGPDPC 16

In assessing the breach and determining the directions, if any, to be

imposed on DSHR in this case, the Commissioner took into account the
following aggravating factors:
(a)

There was actual loss of DSHR’s Data as the hacker managed to

access and delete the entire Database;
(b)

There was also the risk of DSHR’s Data being misused (e.g. the

front and back image of affected individuals’ NRIC could be used to
commit identity theft); and
(c)

DSHR’s failure to password protect the Database was a serious

lapse of a basic and integral IT security arrangement.
18

The Commissioner also took into account the following mitigating

factors:
(a)

DSHR implemented reasonable corrective measures to address

the technical flaws that resulted in the Incident. DSHR also notified all
affected individuals via SMS; and
(b)
19

DSHR cooperated with the investigations.

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

hereby directs DSHR to pay a financial penalty of $33,000.00 within 30 days
from the date of the Commissioner’s direction, failing which, interest at the rate
specified in the Rules of Court4 in respect of judgment debts, shall accrue and

4

Cap 322, R5, 2014 Rev Ed.

9

DS Human Resource Pte. Ltd.

[2019] SGPDPC 16

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

YEONG ZEE KIN
DEPUTY COMMISSIONER
FOR COMMISSIONER FOR PERSONAL DATA PROTECTION

10

",Financial Penalty,bfa125f8a297fb6c613081fe6e35c98b3cd9a4bc,"[""pdf-content"",""timestamp"",""decision"",""pdf-url"",""tags"",""nature"",""url"",""title"",""date"",""description""]"
2023-10-01T11:02:10+08:00,fbd32491db44d3d0c97aa12a99cefd61ec954264,164,164,1,952,"A financial penalty of $8,000 was imposed and directions were issued to Matthew Chiong Partnership for breaches of the PDPA. The organisation did not make reasonable security arrangements to prevent the unauthorised disclosure of its clients’ personal data and failed to put in place data protection policies to comply with the provisions of the PDPA.","[""Accountability"", ""Protection"", ""Financial Penalty"", ""Legal"", ""Law Firm""]",2019-06-03,https://www.pdpc.gov.sg/-/media/Files/PDPC/PDF-Files/Commissions-Decisions/Grounds-of-Decision---Matthew-Chiong-Partnership-030619.pdf,"Accountability, Protection",Breach of the Openness and Protection Obligations by Matthew Chiong Partnership,https://www.pdpc.gov.sg/all-commissions-decisions/2019/06/breach-of-the-openness-and-protection-obligations-by-matthew-chiong-partnership,2019-06-03,"PERSONAL DATA PROTECTION COMMISSION

[2019] SGPDPC [7]
Case No DP-1709-B1138

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

And

Matthew Chiong Partnership

… Organisation

DECISION

Matthew Chiong Partnership

[2019] SGPDPC [7]
Tan Kiat How, Commissioner — Case No DP-1709-B1138
3 June 2019
Background
1

An administrative staff of Matthew Chiong Partnership (the

“Organisation”) mistakenly sent out email correspondences meant for a client
(the “Complainant”) to an incorrect email address on two separate occasions.
Additionally, a third email correspondence was mistakenly sent by the
Managing Partner and Data Protection Officer of the Organisation (the
“Managing Partner”) to the Complainant with an attachment which
mistakenly contained the names of two other clients of the Organisation. The
Commissioner found the Organisation to be in breach of its Protection
Obligation and Openness Obligation under the Personal Data Protection Act
2012 (“PDPA”). The Commissioner’s findings and grounds of decisions are set
out below.
Material Facts
2

The Organisation is a Singapore-registered law firm which provides

estate planning services and handles property transactions for its clients.
3

On 28 August 2017, an administrative staff from the Organisation sent

an email (“Email 1”) to two individuals informing them that the legal

Matthew Chiong Partnership

[2019] SGPDPC 7

documents for their property refinancing had been prepared and were ready for
signature. One of the email addresses was incorrect as the administrative staff
made an error in the email address – as an example and only for illustration
purposes, by typing AAA@yahoo.com instead of ZAAA@yahoo.com. The
incorrect email address was a valid email address as the Complainant had sent
a test email to that email address after Email 1 was sent and did not receive a
mail delivery failed message. This mistake was identified by the sister of the
Complainant (""Sister""), one of the intended recipients, who informed the
Complainant. Once the Complainant informed the administrative staff, the
administrative staff re-sent the email to the Complainant. Email 1 disclosed
information including the email address of the Sister, the residential address of
Complainant and Sister, and the name of the bank in relation to the Complainant
and Sister's mortgage of their property.
4

The second incident occurred on 15 September 2017 when the same

administrative staff sent an email (“Email 2”), enclosing a letter addressed to a
bank from the Organisation and a redemption statement issued by the bank, to
the same incorrect email address. Email 2 disclosed information including the
full names, NRIC numbers, residential address, financial data such as the
mortgage account information (consisting the name of bank, account holders’
full names, loan account number, file reference number, name of security, and
redemption statement of account for the month of September 2017) of the
Complainant and her Sister. Following the two incidents, the Managing Partner
apologised to the Complainant and Sister and offered: (i) a full refund of legal
costs; and (ii) to absorb all the disbursements incurred in handling the property
transaction.
5

Subsequently, on 29 September 2017, the Managing Partner sent an

email (“Email 3”) to the Complainant and Sister enclosing two attachments: (i)

2

Matthew Chiong Partnership

[2019] SGPDPC 7

a Letter of Approval from the Central Provident Fund (“CPF”) Board; and (ii)
a blank Authorisation Use of CPF for Purchase of Private Property form. The
Complainant noticed that there were two different documents contained within
the Letter of Approval, and one of the pages reflected the full names of two
other individuals (“Other Clients”), who were clients of the Organisation, and
who were unrelated to the Complainant’s property transaction and unknown to
the Complainant and Sister.
6

The table below sets out the three emails sent (collectively, the

“Emails”) and the enclosed attachments (collectively, the “Attachments”)
along with a description of the corresponding information that was disclosed
without authorisation.

Email 1

Email 2

Type of Document

Information Disclosed

Correspondence



The Sister's email address;



the Complainant’s and
residential address; and



the name of the bank in relation to
the mortgage of the property.

1. A
letter
addressed to a
bank from the
Organisation



The Complainant’s and Sister’s full
names;



the Complainant’s
NRIC numbers;

and

Sister’s

2. A
redemption
statement issued
by the bank



the Complainant’s and
residential address; and

Sister’s

3

Sister's

Matthew Chiong Partnership

Email 3

[2019] SGPDPC 7



financial data such as the mortgage
account information which consists
of the name of the bank, account
holders’ full names, loan account
number, repayment information, and
information relating to the collateral
for the loan.

1. A
Letter
of 
Approval from
CPF Board

The full names of Other Clients who
were
other
clients
of
the
Organisation, within 2 pages of
documents which formed part of a
larger 10-page legal document
relating to the Other Clients.

2. A
blank
Authorisation
Use of CPF for
Purchase
of
Private Property
Form

The Commissioner’s Findings and Assessments
Main Issues for Determination
7

The issues to be determined in the present case are as follows:
(a)

whether the information disclosed by the Emails and

Attachments constituted personal data within the meaning of the PDPA;
(b)

whether the Organisation had implemented reasonable security

arrangements to protect the personal data in its possession or under its
control, as required pursuant to section 24 of the PDPA; and
(c)

whether the Organisation had put in place policies and practices

relating to personal data, as required pursuant to section 12 of the PDPA.

4

Matthew Chiong Partnership

[2019] SGPDPC 7

Issue (a): Whether the information disclosed by the Emails and Attachments
constituted personal data
(i) The information disclosed in the Emails and Attachments were personal data
8

Section 2(1) of the PDPA defines personal data as data, whether true or

not, about an individual who can be identified from either that data, or from that
data and other information to which the organisation has or is likely to have
access. Given that the full names, residential address, NRIC numbers, email
addresses and financial data of the Complainant and Sister were disclosed, it
would have been possible to identify the Complainant and Sister from the
information contained in the Emails and Attachments. Taking just the email
address of the Complainant as an example, given that it contained the partial
name of the Complainant, it in itself would potentially allow a third party to
identify the Complainant. The disclosure of the full names of the Other Clients
in Email 3 would also have allowed a third party to identify these individuals.
Accordingly, the information contained in each of the Emails and Attachments
or collectively, amounted to personal data within the meaning of section 2(1) of
the PDPA.
(ii) The personal data contained in Emails and Attachments were sensitive in
nature
9

The earlier decisions of the Commissioner have identified that certain

information by reason of the context of their disclosure or by their very nature
would be considered as personal data that is sensitive.1 These include but are

1

See Re Credit Counselling Singapore [2017] SGPDPC 18 at [11].

5

Matthew Chiong Partnership

[2019] SGPDPC 7

not limited to NRIC/Passport numbers2, financial data such as bank account
details containing the name of the bank, the bank account number and the
account holder’s name3, and insurance policy data such as the premium amount
and type of coverage4.
10

As set out in the table at paragraph 6, the following personal data had

been disclosed: the bank name, the NRIC numbers of the Complainant and
Sister, loan account number of the bank, repayment information and collateral
information. The disclosure of such information could have led to harm to the
Complainant and Sister as such financial information could have exposed the
Complainant and Sister to the risk of fraud and identity theft. As such, the
personal data of the Complainant and Sister which had been disclosed, when
taken as a whole, constituted sensitive personal data.
11

Since the Organisation is in the business of providing legal services, and

handles large volumes of personal data on a day to day basis, the Organisation
and its staff members should be vigilant in its handling of personal data. The
fact that the same administrative staff managed to send the emails to the
incorrect email address on two separate occasions within a period under one
month – ie between 28 August and 15 September 2017 – despite being told of
the mistake demonstrated that a culture of care and responsibility towards the
handling of the personal data had not been sufficiently ingrained within the
Organisation.

2

Re JP Pepperdine Group Pte. Ltd. [2017] SGPDPC 2 at [22]; and Re Singapore
Telecommunications Limited and another [2017] SGPDPC 4 at [26].

3

Re AIA Singapore Private Limited [2016] SGPDPC 10 at [19].

4

Re Aviva Ltd and another [2016] SGPDPC 15 at [38].

6

Matthew Chiong Partnership

[2019] SGPDPC 7

Issue (b): Whether the Organisation has complied with its Protection
Obligation under Section 24 of the PDPA
(i) Personal data of a sensitive nature is subjected to a higher standard of
protection
12

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

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

In Re Credit Counselling Singapore [2017] SGPDPC 18 (“Re Credit

Counselling Singapore”)5 and Re Aviva Ltd [2017] SGPDPC 14 (“Re Aviva Ltd
[2017]”)6, the Commissioner opined that organisations are required to take extra
precautions and ensure that higher standards of protection are accorded to
sensitive personal data due to the actual or potential harm, and the severity of
such harm arising from the unauthorised disclosure of such data. This point was
again emphasised in the recent decision of Re Aviva Ltd [2018] SGPDPC 4
where sensitive personal data was disclosed due to a lack of safeguards put in
place to protect against the unauthorised disclosure of personal data in the
organisation’s enveloping process. The PDPC’s Advisory Guidelines on Key
Concepts in the Personal Data Protection Act urge organisations to “implement
robust policies and procedures for ensuring appropriate levels of security for
personal data of varying levels of sensitivity”.7

5

Re Credit Counselling Singapore [2017] SGPDPC 18 at [25] and [26].

6

Re Aviva Ltd [2017] SGPDPC 14 at [17] and [18].

7

PDPC, Advisory Guidelines on Key Concepts in the Personal Data Protection Act
(revised on 27 July 2017) at [17.3].

7

Matthew Chiong Partnership

14

[2019] SGPDPC 7

Further, the Commissioner in Re Credit Counselling Singapore advised

that suitable checks and controls be implemented before emails containing
sensitive personal data are sent.8 These may range from process-based
supervision to technological controls like using the “mail-merge” function in
Outlook. Credit Counselling Singapore had, after the data breach, automated the
process of sending emails using mail-merge software. The Organisation in this
case should similarly consider putting in place a similar technological solution
since it has to churn out standard form emails regularly.
15

However, the Commissioner “is not suggesting that organisations

would need, for example, to have the added layer of supervision in all cases
where emails containing personal data are being sent out … organisations are
to put in place security arrangements that are commensurate with the sensitivity
of the data in question – a balance of considerations.”9 The PDPC’s guide to
preventing accidental disclosure when processing and sending personal data
encourages organisations to have a process to double check and verify: (i) the
recipients’ email addresses; (ii) whether the right attachments containing the
correct personal data are attached; and (iii) whether the attachments are for the
intended recipients before sending the emails out.10 Therefore, implementing
additional checks and controls when handling sensitive personal data is not a
mandatory requirement but one that should be adopted where appropriate.
Ultimately, the facts of the case and the type of personal data being handled will
influence whether or not the current checks and controls implemented in the
particular organisation are sufficient.

8

Re Credit Counselling Singapore [2017] SGPDPC 18 at [29].

9

Re Credit Counselling Singapore [2017] SGPDPC 18 at [30].

10

PDPC, Guide to Preventing Accidental Disclosure When Processing and Sending
Personal Data (20 January 2017) at [2.1]

8

Matthew Chiong Partnership

[2019] SGPDPC 7

(ii) The Organisation failed to implement adequate security arrangements
which led to the unauthorised disclosure of personal data
16

The Organisation explained that the unauthorised disclosure in the

Emails were caused by human error and failure to conduct thorough checks of
the recipients’ email addresses and the content of the attachments before
sending out the email to the recipients. For Email 1 and Email 2, the
administrative staff had entered an incorrect email address which the
Organisation claims has never occurred when she had sent out electronic
communications on previous occasions. For Email 3, the Letter of Approval was
printed on recycled paper and scanned by an employee of the Organisation.
However, the employee had scanned the Letter of Approval using the doublesided scanning mode which was the previous setting left on the scanner. As a
result, a page containing the names of the Other Clients who were also clients
of the Organisation was scanned together with the Letter of Approval.
17

The excuse that this was a one-off mistake by the employees and the

Managing Partner of the Organisation, and not due to any lack of or failure to
implement reasonable security arrangements pursuant to section 24 PDPA was
duly considered by the Commissioner. This was an alternative position
previously considered by the Commissioner in Re Furnituremart.sg [2017]
SGPDPC

7

(“Re

Furnituremart.sg”).11

The

Commissioner

in

Re

Furnituremart.sg ultimately concluded that the organisation lacked the
necessary policies and practices to protect personal data.12 Similarly, the
Commissioner also takes the view in this case that the Organisation failed to

11

Re Furnituremart.sg [2017] SGPDPC 7 at [11].

12

Re Furnituremart.sg [2017] SGPDPC 7 at [17].

9

Matthew Chiong Partnership

[2019] SGPDPC 7

implement reasonable security arrangements, and the incident could not be
considered as a one-off inadvertent disclosure.
18

As a starting position, under section 53(1) of the PDPA, is that the

Organisation is liable for the acts and conduct of its employees in relation to the
unauthorised disclosure of the personal data. In response to the Commissioner’s
request of the details of the Organisation’s security arrangements, the
Organisation stated that: (i) all employees were briefed on the need to keep
private and confidential personal data of their clients on a regular basis; and (ii)
all employees were advised to cut and paste email addresses of clients from a
legitimate source of information or click the “Reply” function to the email sent
from a client rather than typing in the email addresses. However, the
Organisation was unable to provide any evidence of such briefings to its
employees.
19

In Re Aviva Ltd [2017], the Commissioner found that “it is insufficient

for the Organisation to solely depend on its employees to carry out their duties
diligently as a type of safeguard against an unauthorised disclosure of personal
data”.13 This case is no different. Therefore, the Commissioner finds that the
Organisation's briefing to and/or giving advice to employees was by itself
insufficient to prevent the unauthorised disclosure of personal data, particularly
given the sensitive nature of the personal data.
20

Further, the nature of the Organisation’s services is a relevant factor to

be taken into consideration. In Re Credit Counselling Singapore, the
Commissioner observed that “… it is foreseeable that there will be risks of

13

Re Aviva Ltd [2017] SGPDPC 14 at [28].

10

Matthew Chiong Partnership

[2019] SGPDPC 7

inadvertent disclosure of sensitive personal data” where the organisation
“routinely handles large volumes of sensitive financial personal data of
individuals”.14 In the present case, the Organisation is a law firm and the staff
handling conveyancing matters handle sensitive personal data on a day-to-day
basis and it was therefore foreseeable that there were risks of inadvertent
disclosure of sensitive personal data. Given the nature of the Organisation’s
work, the Organisation ought to be subject to a higher level of care and
responsibility for its clients’ personal data.
21

The Commission released a Guide to Data Protection Impact

Assessment which is intended to assist organisations interested in conducting
data protection risk assessments. The Commissioner encourages the
Organisation to carry out a data protection risk assessment on its conveyancing
department, which should help to identify and address the specific risks that
exists in its operational processes. This will assist the Organisation to put in
place effective risk mitigation measures.
22

Given the Commissioner's findings above that the Organisation did not

put in place adequate security arrangements to protect the personal data of its
clients, it is hereby concluded that the Organisation was in breach of the
Protection Obligation under section 24 of the PDPA.

14

Re Credit Counselling Singapore [2017] SGPDPC 18 at [32].

11

Matthew Chiong Partnership

[2019] SGPDPC 7

Issue (c): Whether the Organisation has complied with its Openness Obligation
under Section 12 of the PDPA
(i) The Organisation did not implement any policies or practices to protect
personal data
23

The investigations revealed that the Organisation did not put any

policies or practices in place to protect personal data. In Re Furnituremart.sg,
the Commissioner decided that “the lack of a written policy is a big drawback
to the protection of personal data … Having a written policy is conducive to the
conduct of internal training, which is a necessary component of an internal data
protection programme”.15 The Organisation’s claim that internal briefings were
conducted to raise staff awareness were unsubstantiated by any supporting
evidence. Nevertheless, even if verbal briefings were indeed given, this in itself
would not be sufficient for the Organisation to discharge its obligations under
section 12 of the PDPA. In general, an organisation should have some form of
written policy or practice in place in relation to protecting personal data
especially if the process is complex or if the organisation frequently deals with
sensitive personal data on a daily basis. A well-drafted written policy has the
advantage over verbal instruction of being a resource that can generally be
subsequently relied upon to provide clarity about the appropriate procedures and
controls to employees and help minimize the chance for any misunderstanding
or miscommunication. This may take the form of written standard operating
procedures in dealing with personal data which would set out the operational
process of how employees should deal with personal data to prevent data
protection breaches. For example, a process which implements the suggestion
set out at paragraph 15 above may be set out in the form of a standard operating
procedure.

15

Re Furnituremart.sg [2017] SGPDPC 7 at [14].

12

Matthew Chiong Partnership

24

[2019] SGPDPC 7

Based on the above, given that the Organisation had not developed and

implemented policies and practices that are necessary to protect personal data,
it is the conclusion of the Commissioner that the Organisation is in breach of
the Openness Obligation under section 12 of the PDPA.
Representations
25

The Organisation, by way of email dated 3 January 2019, requested that

the imposition of financial penalty amount be removed or that the amount be
reduced. In this regard, the Organisation made the following representations:
(a)

the disclosure was not a deliberate act on the part of the

Organisation or any of its staff;
(b)

the incidents related to one single conveyancing case involving

2 individuals;
(c)

the Organisation waived all legal costs and expenses incurred in

the matter in which it advised the Complainant;
(d)

the information disclosed is generally regarded as sensitive but

that it had absolutely no interest to the recipient; and
(e)

the unauthorised disclosure was not due to lack of supervision

and it was not possible to check all email addresses every time there is
an email to be sent out. The staff member who committed the error was
50 years old and probably has long-sightedness. The staff was not in the
email thread and so she could not have copied the email address from
the header of prior emails to the client. The said staff has since left the
Organisation’s employment.

13

Matthew Chiong Partnership

26

[2019] SGPDPC 7

The Commissioner in deciding to impose a financial penalty and on the

appropriate quantum of the financial penalty had already taken into
consideration the issues raised by the Organisation and as set out at paragraph
25(a) to (c) above.
27

With regard to the issue raised by the Organisation and set out at

paragraph 25(d), the Commissioner notes that the Organisation agrees that the
information disclosed in these incidents is sensitive.
28

With regard to the issue raised by the Organisation and set out at

paragraph 25(e) above, the basis for the finding of a breach of the Organisation’s
obligation under section 24 of the PDPA was that the Organisation failed to
implement reasonable security arrangements. In this regard, the Commissioner
does not expect organisations to check the email addresses every time there is
an email to be sent out. However, as explained above at paragraph 15, the
Organisation ought to have implemented a considered process to verify that
emails are correctly addressed to the intended recipient – the Organisation did
not adduce any evidence of such a considered process. Nevertheless, the
Commissioner has decided on compassionate grounds to reduce the quantum of
the financial penalty set out in the preliminary decision issued to the
Organisation, given that the staff who committed the error was advanced in age
and long-sighted.
The Commissioner’s Directions
29

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

directions as it thinks fit in the circumstances. This may include directing the
Organisation to pay a financial penalty of such amount not exceeding S$ 1
million as the Commissioner thinks fit.

14

Matthew Chiong Partnership

30

[2019] SGPDPC 7

In assessing the breach and determining the directions to be imposed on

the Organisation in this case, the Commissioner took into account the
Organisation’s dilatory conduct during investigations. It had been neither
cooperative nor forthcoming in its responses to the Notice to Require Production
of Documents and Information (“NTP”) issued by the Commissioner as part of
its investigations. The Organisation took a month to respond to the first NTP
and second NTP despite being sent reminders by the Commissioner on several
occasions:
(a)

The first NTP was sent on 12 December 2017 with a deadline to

respond by 22 December 2017. The Organisation failed to meet the
deadline and only on 2 January 2018, more than a week after the expiry
of the deadline, did the Organisation write requesting for an extension
of time to respond. The extension sought was up to 4 January 2018. The
Organisation was granted an extension of time to respond by 10 January
2018. The organisation finally responded on 11 January 2018.
(b)

The 2nd NTP was sent on 22 January 2018 requiring the

Organisation to respond by 1 February 2018. The Organisation again
failed to meet the deadline and did not even request for an extension of
time to respond. The investigating officer had to call the Organisation
on 6 February 2018 to ask the Organisation why it had failed to respond
to the 2nd NTP within the deadline. During this conversation, the
Organisation requested for an extension of time of the deadline. The
investigating officer informed the Organisation that she would issue a
reminder with a deadline to respond by 15 February 2018. The reminder
was issued on 7 February 2018. The Organisation failed to comply with
this new deadline. In fact, no correspondence from the Organisation was
received even by 20 February 2018. On 20 February, the investigating

15

Matthew Chiong Partnership

[2019] SGPDPC 7

officer called the Organisation as a further reminder. Only after this did
the Organisation respond to the 2nd NTP on 23 February 2018.
31

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

hereby directs the Organisation to pay a financial penalty of S$8,000 within 30
days from the date of the Commissioner’s direction, failing which, interest, at
the rate specified in the Rules of Court in respect of judgment debts, shall be
payable on the outstanding amount of such financial penalty.
32

In addition, the Commissioner hereby issues the following directions to

the Organisation:
(a)

to implement a data protection policy and internal guidelines or

standard operating procedures to comply with the obligations under the
PDPA;
(b)

for all employees of the Organisation handling personal data to

attend a training course on the obligations under the PDPA and the
Organisation’s data protection policies; and
(c)

to complete the above directions within 60 days from the date of

this decision and inform the office of the Commissioner of the
completion thereof within one week of implementation.

YEONG ZEE KIN
DEPUTY COMMISSIONER
FOR COMMISSIONER OF PERSONAL DATA PROTECTION

16

",Financial Penalty,30f9d65dadfb6fbd9263c5c5f68b5faccfb0e878,"[""pdf-content"",""timestamp"",""decision"",""pdf-url"",""tags"",""nature"",""url"",""title"",""date"",""description""]"
2023-10-01T11:02:10+08:00,fbd32491db44d3d0c97aa12a99cefd61ec954264,192,192,1,952,"Directions were issued to Habitat for Humanity Singapore for breaches of the PDPA.  The organisation did not make reasonable security arrangements to prevent unauthorised disclosure of its volunteers’ personal data, failed to put in place data protection policies, and omitted to communicate data protection policies and practices to its staff.","[""Accountability"", ""Protection"", ""Directions"", ""Social Service""]",2018-05-03,https://www.pdpc.gov.sg/-/media/Files/PDPC/PDF-Files/Commissions-Decisions/Grounds_of_Decision_Habitat_for_Humanity_Singapore_030518.pdf,"Accountability, Protection",Breach of Openness and Protection Obligations by Habitat for Humanity Singapore,https://www.pdpc.gov.sg/all-commissions-decisions/2018/05/breach-of-openness-and-protection-obligations-by-habitat-for-humanity-singapore,2018-05-03,"PERSONAL DATA PROTECTION COMMISSION

[2018] SGPDPC 9

Case No DP-1707-B0971

In the matter of an investigation under section 50(1)
of the Personal Data Protection Act 2012
And
Habitat for Humanity Singapore Ltd
… Organisation

DECISION

Habitat for Humanity Singapore Ltd
[2018] SGPDPC 9
Yeong Zee Kin, Deputy Commissioner — Case No DP-1707-B0971
3 May 2018
Background
1

On 20 July 2017, the Organisation sent out an email to 32 of its

volunteers with a PDF attachment comprising a batch of community
involvement programme (“CIP”) letters (the “CIP Letters”) acknowledging
the participation of each volunteer at an event organised by the Organisation
(the “Incident”). The Personal Data Protection Commission (the “PDPC”) was
informed of the Incident on 22 July 2017 and commenced its investigations
thereafter. I set out below my findings and grounds of decision based on the
investigations carried out in this matter.
Material Facts
2

The Organisation is a registered charity under the National Council of

Social Services, which objectives include seeking to eliminate poverty housing
worldwide by providing decent and affordable housing. In furtherance of its
objectives, the Organisation organises community involvement programmes,
where volunteers can participate in activities such as mass clean-up events.
After such events, the Organisation would generally send out a CIP letter to
acknowledge and verify each individual volunteer’s participation.

Habitat for Humanity Singapore Ltd

3

[2018] SGPDPC 9

The Incident involved the disclosure of a batch of CIP Letters in an email

(the “Email”) that was prepared by a manager (the “Manager”) in the
Organisation. The CIP Letters were created using the mail merge function in
Microsoft Word which would fill in a CIP letter template with the names and
NRIC numbers of the volunteers. This created a single Microsoft Word
document containing the CIP Letters for all the volunteers, which the Manager
then converted from Microsoft Word to PDF format. The Manager then sent the
PDF containing the entire batch of CIP Letters to another member of staff
(“Admin Staff”), along with the volunteers’ email addresses and instructed the
Admin Staff to send out the CIP Letters.
4

The Organisation’s usual practice was for the document containing the

entire batch of CIP Letters to be segregated and split into individual CIP Letters
before each CIP Letter was individually sent to its respective volunteers.
However, in this case, neither the Manager nor the Admin Staff had prepared
and/or handled any CIP Letters prior to the Incident. The Manager failed to
instruct the Admin Staff on the proper procedure.
5

On 20 July 2017, the Admin Staff sent a mass email to all the volunteers

who were involved in the mass clean-up event, attaching the PDF document
which contained the entire batch of CIP Letters. As a result, the PDF attachment
containing the CIP Letters revealed the names and NRIC numbers of all the
volunteers who had participated in the Organisation’s mass clean-up event.
Additionally, the Email was also sent with the email addresses of all the
recipients in the “cc” field. Consequently, the Organisation received two emails
from the volunteers who had received the Email, expressing their concern that
their personal data had been disclosed to other parties without their consent.

2

Habitat for Humanity Singapore Ltd

[2018] SGPDPC 9

Findings and Basis for Determination
6

The issues for determination are:
(a)

whether the Organisation complied with its obligations under

section 12 of the PDPA; and
(b)

whether the Organisation was in breach of section 24 of the

PDPA.
7

As a preliminary point, the names, NRIC numbers and email addresses

disclosed in the Email and CIP Letters fall within the definition of “personal
data” under section 2(1) of the PDPA, as it was clearly possible to identify an
individual from that data.
8

Pursuant to section 53(1) of the PDPA, any act done or conduct engaged

in by a person in the course of his employment shall be treated for the purposes
of the PDPA as done or engaged in by his employer as well as by him, regardless
of whether it was done or engaged in with the employer’s knowledge or
approval. The Organisation is therefore responsible for its employees’ conduct
in relation to the Incident.
(a)
Whether the Organisation complied with its obligations under section
12 of the PDPA
9

Section 12(a) of the PDPA requires an organisation to develop and

implement policies and practices that are necessary to meet its obligations under
the PDPA. Section 12(c) of the PDPA also requires the organisation to
communicate to its staff information about such policies and practices.
10

The Organisation claimed to have instructed its employees on the

Organisation’s obligations under the PDPA and the importance of safeguarding
3

Habitat for Humanity Singapore Ltd

[2018] SGPDPC 9

its volunteers and donors’ personal data. Employees who were required to deal
with personal data were also briefed on the following data protection practices
and procedures “on a need basis”:
(a)

to use the “bcc” function when sending out mass emails;

(b)

to send the CIP Letters individually;

(c)

to avoid sharing collected personal data with unauthorised third

parties;
(d)

to contact individuals only for purposes that they have given

consent;
(e)

to use personal data only for the purposes for which it was

collected; and
(f)
11

to secure all documents containing personal data safely.

However, there were no documented policies, practices or procedures in

relation to sending out the CIP Letters. Indeed, the Incident could very well have
been averted if the Organisation had implemented, and documented, a standard
operating procedure for the sending out of the CIP Letters. By the
Organisation’s own admission, the Manager had omitted to instruct the Admin
Staff on the Organisation’s usual procedure for sending out the CIP Letters and
she “should have written down the instruction clearly for [the Admin Staff],
which [she] had forgotten to do.”
12

I take this opportunity to reiterate the benefits and importance of

documenting an organisation’s data protection policies and practices in a written

4

Habitat for Humanity Singapore Ltd

policy as

emphasised in

[2018] SGPDPC 9

Re Furnituremart.sg [2017] SGPDPC 7

(“Furnituremart.sg”) at [14]:
“The lack of a written policy is a big drawback to the protection
of personal data. Without having a policy in writing, employees
and staff would not have a reference for the Organisation’s
policies and practices which they are to follow in order to
protect personal data. Such policies and practices would be
ineffective if passed on by word of mouth, and indeed, the
Organisation may run the risk of the policies and practices
being passed on incorrectly. Having a written policy is
conducive to the conduct of internal training, which is a
necessary component of an internal data protection
programme.”

13

In this regard, the Organisation was unable to demonstrate or produce

any evidence that it had developed and implemented policies and practices
necessary for it to comply with its obligations under the PDPA in respect of
sending out the CIP Letters.
14

In addition, the Organisation did not provide any formalised data

protection training for its employees. As the Commissioner observed in Re
National University of Singapore [2017] SGPDPC 5 (at [21]), data protection
training may fall under both the openness obligation (specifically, section 12 of
the PDPA) and the protection obligation (section 24 of the PDPA). Data
protection training is an effective mode of communication of the Organisation’s
policies and practices to fulfil the openness obligation (section 12(c) of the
PDPA).
15

The Manager’s failure to communicate the Organisation’s data

protection policy was evidenced by the Admin Staff’s lack of awareness of the
use of the “bcc” function and the implications of her actions in respect of the
Email. Although the Admin Staff claimed to have been instructed on the “rules
with regard to volunteers’ personal details”, the fact that she: (a) did not query

5

Habitat for Humanity Singapore Ltd

[2018] SGPDPC 9

whether it was appropriate to send the entire batch of CIP Letters containing
personal data to all the volunteers; and (b) did not think to check whether the
email addresses of the recipients of a mass email should be inserted in the “bcc”
field instead of the “to” or “cc” fields suggests that there was a lack of awareness
of the Organisation’s obligations under the PDPA.
16

Accordingly, I find that the Organisation has breached its openness

obligation, given that it did not develop and implement a data protection policy
as necessary for the Organisation to meet its obligations under the PDPA at the
time of the Incident, and it did not communicate its data protection policies and
practices to its staff, as required under sections 12(a) and (c) of the PDPA.
(b)

Whether the Organisation was in breach of section 24 of the PDPA

17

Section 24 of the PDPA requires an organisation to protect the 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.
18

In this case, the Organisation’s informal practices and verbal reminders

“on a need basis” were an insufficient security arrangement for the purposes of
compliance with section 24 of the PDPA. The Organisation did not implement
any checks and controls to prevent or minimise the risk of unauthorised
disclosure of personal data. Knowing that the output produced by the Microsoft
Word mail merge function was a single file containing the CIP Letters for all
volunteers in the batch, the Organisation did not implement technical

6

Habitat for Humanity Singapore Ltd

[2018] SGPDPC 9

arrangements such as installing IT tools1 that would have enabled the CIP
Letters to be generated from the CIP letter template as separate documents. At
the minimum, greater awareness of the need to protect the personal data of
volunteers would have prompted the Admin Staff to process the PDF or
Microsoft Word document containing the entire batch of CIP Letter manually
in order to split the document into individual PDF files. The Manager would
also have had a role to play in ensuring that this was done and could have
implemented simple process checks to identify errors. Furthermore, technical
controls could also have been installed to remind employees to use the “bcc”
function when multiple email addresses are pasted in the “to” or “cc” field.
Unnecessary disclosure of NRIC numbers
19

At this juncture, I observe that the disclosure of the volunteers’ NRIC

numbers in the CIP Letters was unnecessary as the CIP Letters had already
referred to the volunteers by their full names. Given that an individual’s NRIC
number is a permanent and irreplaceable identifier which can be used to unlock
large amounts of information relating to the individual, organisations should not
disclose an individual’s NRIC number except where it is required under the law
or where it is necessary to accurately establish and verify the identity of the
individual by way of the same. It is not apparent to me that the need to identify
an individual in a CIP Letter was to such a degree of specificity that his or her
NRIC had to be included. The nature and function of a CIP Letter did not
necessitate the publication of the volunteer’s NRIC number.

1

There were IT tools reasonably available that would have enabled the CIP Letters to
be generated from a template as separate documents. For instance, the installable PDF
Split & Merge program allows a single PDF or Microsoft Word output from a mail
merge operation to be processed into individual PDF files.

7

Habitat for Humanity Singapore Ltd

20

[2018] SGPDPC 9

Organisations that choose to disclose more sensitive data than are

required for their business or legal purposes have to be able to defend such
decisions and bear the burden of ensuring an appropriate level of security for
the personal data of varying levels of sensitivity. As observed in Re Aviva Ltd
[2017] SGPDPC 14 (at [18]):
“The Advisory Guidelines on Key Concepts in the PDPA states
that an organisation should “implement robust policies and
procedures for ensuring appropriate levels of security for
personal data of varying levels of sensitivity”. This means that
a higher standard of protection is required for more
sensitive personal data.”
[Emphasis added.]

21

In the premises, I find that the Organisation failed to make reasonable

security arrangements to protect the personal data in its possession and control,
as the Organisation:
(a)

did not put in place basic administrative security arrangements

such as setting out its data protection policies and procedures in writing;
(b)

did not implement any checks and controls to ensure that its

employees were complying with its data protection practices and
policies;
(c)

did not provide any formalised data protection training for its

employees;
(d)

failed to properly supervise the employees who were in charge

of preparing and sending out the CIP Letters; and
(e)

did not have any other form of security arrangement to protect

its volunteers’ personal data.

8

Habitat for Humanity Singapore Ltd

[2018] SGPDPC 9

Directions
22

Having found that the Organisation is in breach of sections 12(a), 12(c),

and 24 of the PDPA, I am empowered under section 29 of the PDPA to give the
Organisation such directions as I deem fit to ensure compliance with the PDPA.
23

In assessing the breach and determining the directions to be imposed, I

took into account, as an aggravating factor, the fact that the personal data
disclosed included the volunteers’ NRIC number, which was of a sensitive
nature.
24

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

the disclosure only affected a limited number of people; and

(b)

the Organisation had cooperated fully in the PDPC’s

investigation.
25

Pertinently, the PDPC has recently issued a public consultation on the

proposed advisory guidelines for NRIC numbers, which, inter alia, discourages
the indiscriminate use of NRIC numbers. Due weight has been given to the
unsatisfactory practices that currently abound. Our practices as a society need
to be improved as we become more knowledgeable about the risks of identity
theft and other identity-related risks (and I do not restrict this caution as
referring only to online risks). In future, similar conduct may call for the
imposition of a financial penalty as proposed changes to the advisory guidelines
on the collection, use and disclosure of NRIC numbers are implemented. This
case should serve as a clarion call for all organisations to start handling personal
data such as NRIC numbers, which are unique and permanent identifiers of
individuals, with a much higher degree of care and discernment than the present.

9

Habitat for Humanity Singapore Ltd

26

[2018] SGPDPC 9

I hereby issue the following directions to the Organisation:
(a)

to conduct a review of all its activities involving the handling of

personal data of its volunteers and donors;
(b)

to put in place a data protection policy, including process

safeguards and written internal policies, such as standard operating
procedures, to comply with the provisions of the PDPA;
(c)

to arrange for personal data protection training for its staff; and

(d)

to complete the above directions within 90 days from the date of

this decision and inform the Deputy Commissioner of the completion
thereof within 1 week of implementation.

YEONG ZEE KIN
DEPUTY COMMISSIONER
FOR PERSONAL DATA PROTECTION

10

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