_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,78,78,1,952,"A financial penalty of $5,000 was imposed on Worksmartly for breaches of the PDPA. First, the Organisation failed to put in place reasonable security arrangements to protect the personal data of its client’s employees. Second, it was also found to be retaining personal data which was no longer necessary for legal or business purposes.","[""Protection"", ""Retention Limitation"", ""Financial Penalty"", ""Admin and Support Services"", ""Database"", ""Public access"", ""Retention""]",2020-11-24,https://www.pdpc.gov.sg/-/media/Files/PDPC/PDF-Files/Commissions-Decisions/Decision----Worksmartly-Pte-Ltd---17092020.pdf,"Protection, Retention Limitation",Breach of the Protection and Retention Limitation Obligations by Worksmartly,https://www.pdpc.gov.sg/all-commissions-decisions/2020/11/breach-of-the-protection-and-retention-limitation-obligations-by-worksmartly,2020-11-24,"PERSONAL DATA PROTECTION COMMISSION Case No. DP-2004-B6162 In the matter of an investigation under section 50(1) of the Personal Data Protection Act 2012 And Worksmartly Pte. Ltd. SUMMARY OF THE DECISION 1. On 2 April 2020, Roche Singapore Pte Ltd (“Roche”) informed the Personal Data Protection Commission (the “Commission”) of a data security incident involving its former vendor, Worksmartly Pte. Ltd. (the “Organisation”). Roche had detected an unauthorised disclosure of their employees’ data on GitHub repository (“GitHub”) on 3 March 2020 (the “Incident”). 2. The Organisation subsequently requested for this matter to be handled under the Commission’s expedited decision procedure. In this regard, the Organisation voluntarily provided and unequivocally admitted to the facts set out in this decision. It also admitted that it was in breach of sections 24 and 25 of the Personal Data Protection Act (the “PDPA”). Background 3. The Organisation was engaged by Roche in 2017 to provide finance and payroll processing services. In order for the Organisation to provide the said services, Roche handed over its employees’ personal data to the Organisation. The contract between the parties was subsequently terminated, and the Organisation’s last day of service was 31 December 2018. The Incident 4. On or around 28 February 2020, one of the Organisation’s employees uploaded a file on the Organisation’s GitHub account (the “File”). When doing so, the employee changed the setting of the GitHub account from “private” to “public” under the mistaken belief that the File would only be accessible to other members of the Organisation. In fact, the change in setting had resulted in the File being accessible to the public. 5. The File contained the personal data of 308 individuals, which comprised Roche’s current and former employees (the “Employees”), and their dependents (the “Dependents”). The personal data included: a. For the Employees: name, NRIC/FIN/Passport number, address, date of birth, race, citizenship, employee ID, Roche email address, role title, employment commencement date, salary, bank account name and numbers and name of bank; and b. For the Dependents: name, NRIC/FIN/Passport number, date of birth and contact number. 6. The File was used for data migration during the initial service engagement in 2017. The File was supposed to have been deleted—along with other files containing Roche’s employees’ data—before the Organisation’s last day of service, i.e. 31 December 2018. However, because the File was stored in a different folder from the other files, the Organisation had inadvertently omitted to delete the File. This led to the File being exposed to the public when the Organisation’s employee set the GitHub folder’s setting to “public” as stated at [4] above. 7. The File was exposed to the public for a period of five days from 28 February 2020 to 3 March 2020. Based on GitHub’s logs, the repository containing the File was accessed 23 times and downloaded 11 times during this time. The Contraventions 8. The Organisation admitted that it lacked checks to manage the correct security settings of its GitHub account and had relied solely on employees to do the right thing. The Organisation also admitted that it had not conducted the necessary housekeeping and maintenance of files, which resulted in retaining the File when it was no longer required for business or legal purposes. 9. In the circumstances, the Deputy Commissioner for Personal Data Protection finds the Organisation in breach of the Protection Obligation under section 24 and Retention Obligation under section 25 of the PDPA. 10. Upon realising the Incident, the Organisation took the following remedial action: a. Immediately set the GitHub access to “private” and deleted the File; b. Reset the passwords for all the databases and servers; c. Conducted housekeeping to ensure removal of obsolete files from GitHub; d. Directed its GitHub account administrator to always set the repositories to “private” and introduced a disciplinary framework for the mishandling of its GitHub accounts. The Decision 11. The Deputy Commissioner for Personal Data Protection notes that the Organisation had admitted to a breach of Protection and Retention Obligations under the PDPA, and had cooperated with the Commission’s investigation and taken prompt remedial action. 12. On account of the above, the Deputy Commissioner for Personal Data Protection directs the Organisation to pay a financial penalty of $5,000 within 30 days from the date of this direction (failing which interest at the rate specified in the Rules of Court in respect of judgment debts shall accrue and be payable on the outstanding amount of such financial penalty until the financial penalty is paid in full). 13. In view of the remedial actions taken by the Organisation, the Commission will not be issuing any other directions. ",Financial Penalty,583ab7758251c5c2e5fe07f3e5f542c582089f9d,"[""pdf-content"",""timestamp"",""decision"",""pdf-url"",""tags"",""nature"",""url"",""title"",""date"",""description""]" 2023-10-01T11:02:10+08:00,fbd32491db44d3d0c97aa12a99cefd61ec954264,79,79,1,952,"A financial penalty of $20,000 was imposed on Times Software, a data intermediary, for: (i) failing to make reasonable security arrangements to prevent the unauthorised disclosure of personal data belonging to the employees of its clients; and (ii) retaining personal data which was no longer necessary for legal or business purposes. Separately, Dentons and TMF were each issued a warning for failing to put in place reasonable security arrangements with Times Software to prevent unauthorised disclosure of the personal data belonging to their employees.","[""Protection"", ""Retention Limitation"", ""Financial Penalty"", ""Legal"", ""Data Intermediary"", ""Functionality"", ""Software""]",2020-11-24,https://www.pdpc.gov.sg/-/media/Files/PDPC/PDF-Files/Commissions-Decisions/Decision---Times-and-Others---18062020.pdf,"Protection, Retention Limitation","Breach of the Protection and Retention Limitation Obligations by Times Software, Breach of the Protection Obligation by Dentons and TMF",https://www.pdpc.gov.sg/all-commissions-decisions/2020/11/breach-of-the-protection-and-retention-limitation-obligations-by-times-software-breach-of-the-protection-obligation-by-dentons-and-tmf,2020-11-24,"PERSONAL DATA PROTECTION COMMISSION [2020] SGPDPC 18 Case Nos.: DP-1802-B1719, DP-1802-B1744, DP-1803-B1834, DP-1804-B1942, DP-1804-B1943 In the matter of an investigation under section 50(1) of the Personal Data Protection Act 2012 And (1) Times Software Pte Ltd (2) Dentons Rodyk & Davidson LLP (3) Liberty Specialty Markets Singapore Pte Limited (4) Red Hat Asia Pacific Pte Ltd (5) TMF Singapore H Pte Ltd … Organisations DECISION Times Software Pte Ltd & Ors [2020] SGPDPC 18 Tan Kiat How, Commissioner — Case Nos. DP-1802-B1719, DP-1802-B1744, DP1803-B1834, DP-1804-B1942, DP-1804-B1943 18 June 2020 Introduction 1 Times Software Pte Ltd (“Times”) is an information technology services vendor that provides various services to its clients. Between January and February 2018, three organisations which directly or indirectly used Times’ services became aware that the personal data of some their current and former employees (the “Employee Data”) had been exposed online from Times’ servers and could be found using the Google search engine (the “Incident”). These three organisations were Dentons Rodyk & Davidson LLP (“Dentons”), Red Hat Asia Pacific Pte Ltd (“Red Hat”) and Liberty Specialty Markets Singapore Pte Limited (“LIU”). Each of these organisations submitted a data breach notification to the Personal Data Protection Commission (the “Commission”) after the Incident. The Facts The Relationship between the Parties and how Times had obtained the Employee Data 2 Dentons had, since 2001, engaged Times to use a payroll software application developed by Times (the “Payroll Software”). The Payroll Software was hosted internally on Dentons’ servers. In or around November 2015, Dentons commissioned the development of a new functionality of the Payroll Software which would enable 1 Times Software Pte Ltd & Ors 2020 SGPDPC [18] Dentons to create customised employee reports. Dentons provided their Employee Data to Times to test this functionality. 3 In December 2015 and February 2016, Red Hat and LIU respectively engaged TMF Singapore H Pte Ltd (“TMF”), a professional services company, for certain HR and payroll services. For this purpose, Red Hat and LIU provided TMF with their Employee Data. 4 In turn, TMF had, since 2008, engaged Times to use the Payroll Software to provide services to its clients, including Red Hat and LIU. The Payroll Software was hosted on TMF’s servers. Sometime between December 2015 and February 2016, TMF provided Times with Red Hat and LIU’s Employee Data. The reason for doing so was disputed by TMF and Times: (a) According to Times, TMF had provided the Employee Data for a one- time exercise which involved data migration and the development of a new functionality within the Payroll Software; (b) In contrast, TMF asserted that the data migration and development of a new functionality within the Payroll Software were two separate and unconnected requests to Times. In this regard, TMF claimed that it had provided the Employee Data of Red Hat’s and LIU’s to Times only for the purposes of data migration, and was not aware of—and did not consent to—Times’ use of the Employee Data to develop the functionality. 5 There was insufficient contemporaneous evidence to support either party’s version of events. In particular, TMF and Times did not have a written agreement on the handing over of the Employee Data which could have provided more context. In any event, there is no need to make a finding on which version of events is to be believed. As explained further at [36] below, the findings regarding TMF’s breach of its Protection Obligation under Section 24 of the Personal Data Protection Act 2012 (“PDPA”) are not dependent on whether TMF had consented to Times’ use of Red Hat’s and LIU’s Employee Data to develop the functionality within the Payroll Software. 2 Times Software Pte Ltd & Ors 2020 SGPDPC [18] The Disclosure of the Employee Data 6 The Employee Data handed over to Times by Dentons and TMF was stored in Times’ File Server System (“FSS”). Between 21 December 2017 and 23 December 2017, Times suffered a hard disk failure in its FSS. To remediate this, Times restored a backup of the data in the FSS on or around 23 December 2017 and reset the FSS operating system settings to their default settings, which included disabling the password protection feature. As the FSS was accessible over the Internet, the Employee Data that was stored in the FSS was exposed to web crawlers and indexed by the Google search engine and stored in Google’s cache. 7 In total, 616 employees had their Employee Data exposed over the Internet from 23 December 2017 to around mid-February 2018. This number comprised 400 employees from Dentons, 162 employees from Red Hat, and 54 employees from LIU. The types of Employee Data which was exposed during the Incident included: (a) For Dentons: name, NRIC or other identification number, residential address, contact number, work designation, duration of employment and base salary; (b) For Red Hat and LIU: name, NRIC or other identification number, date of birth, marital status, nationality, race, base salary, bank account information, income tax account number, addresses and mobile number. 8 Upon discovery of the Incident, the organisations took the following remedial actions: (a) Times: (i) Took action to take down all links to the Employee Data by contacting Google and other search engines (i.e., Bing and Archive.org); (ii) Took all server hosting development files offline so that they were no longer available on the Internet and could only be accessed internally via Local Area Network with proper authentication; 3 Times Software Pte Ltd & Ors (iii) 2020 SGPDPC [18] Developed additional policies and SOP on data handling for its employees, which included the following requirements: (A) Heads of departments are now required to conduct a weekly audit to ensure sensitive files are destroyed upon completion of work; (B) Cross-department audits are to be done on a monthly basis, as well as upon completion of work; (C) Random audits are to be done by the IT manager on a bi- monthly basis; and (D) Servers published online will no longer accept unencrypted files. (b) LIU: (i) Imposed more stringent contractual provisions on TMF with regard to the services it is providing including dealing with data breaches or the protection of personal data; (ii) Worked with Times to ensure that all relevant data, including the Employee Data, had been removed from Times’ environments; (iii) The Liberty Mutual Global IT Team undertook a comprehensive security review of TMF’s services; and (iv) (c) Notified all its current employees of the Incident. Red Hat: (i) Being the first party to discover the breach, notified Google to take down the Employee Data; (ii) Notified all current employees and former employees of the Incident and offered free credit monitoring service to the affected employees; and 4 Times Software Pte Ltd & Ors (iii) 2020 SGPDPC [18] Obtained assurance from TMF and Times that Times had disabled the internal folder from public view, and that Times would perform audits to ensure all servers published on the internet that are meant for internal use were password-protected. (d) Dentons: (i) Notified its employees of the Incident; and (ii) Obtained assurance from Times that all servers connected to the Internet were password protected. (e) TMF: (i) Ceased to allow Times to retain any of its clients’ information for development purposes, and set up a UAT environment for Times for future development of additional functionalities. Findings and Basis for Determination Breach by Times of Sections 24 and 25 of the PDPA 9 Times was a data intermediary1 of Dentons as it processed personal data on behalf of, and for the purposes of Dentons. As explained further at [27] below, Times was also a data intermediary of TMF as it processed personal data on behalf of, and for the purposes of TMF, the relevant data here being Red Hat’s and LIU’s Employee Data. 10 A data intermediary is subject to both the Protection Obligation and the Retention Limitation Obligation under Section 242 and Section 253 of the PDPA. The Commission’s investigations showed that Times had breached both these obligations. Section 2 of the PDPA defines “data intermediary”. Section 24 of the PDPA requires organisations to protect personal data in their possession or under its control by making reasonable security arrangements to prevent unauthorised access, collection, use, disclosure, copying, modification, disposal or similar risks. 3 Section 25 of the PDPA requires an organisation to cease to retain its documents containing personal data, or remove the means by which the personal data can be associated with particular individuals, as soon as it is 1 2 5 Times Software Pte Ltd & Ors 11 2020 SGPDPC [18] In relation to the Protection Obligation, Times had breached it in two ways. First, the processes in remediating the hard disk failure in its FSS fell short of the standard required under Section 24 of the PDPA. Times’ Standard Operating Protocol (“SOP”) required the employee who carried out the server restoration to enable the authentication function, i.e. password-protect function, so that only a user with proper credentials would be granted access to the data in the FSS. The employee’s supervisor was also required to check that the authentication function was enabled. However, the relevant employee had failed to enable the authentication function after the server restoration. This was not discovered by the employee’s supervisor as the supervisor did not take any measures to confirm that the authentication function was enabled. 12 It can be seen that even though Times had SOPs in place, the fact Times had not detected the employee’s error in not enabling the authentication function shows that the security arrangement was not sufficiently reasonable. As set out in Re Marshall Cavendish Education Pte Ltd [2019] SGPDPC 34 at [21], “relying solely on employees to perform their tasks diligently is not a sufficiently reasonable security arrangement, and the organisation would need to take proactive steps to protect personal data”. Given the amount and type of personal data that Times was processing, Times should have ensured that their SOP included specific procedures that were designed to reasonably detect non-compliance and to discourage deliberate, reckless or careless failures to adhere to the SOP by its employees. 13 Second, Times’ other internal policies also fell short of reasonable protection expected for an organisation that handles the amount and type of personal data that Times handled: (a) Times had poor password management policies in place. It was the prevailing practice of Times’ employees to set the same password to the FSS prior to and after a server restoration. While this may be permissible for certain reasonable to assume that the purpose for which that personal data was collected is no longer being served by the retention of the personal data, and retention is no longer necessary for legal or business purposes. 6 Times Software Pte Ltd & Ors 2020 SGPDPC [18] more routine restorations in the course of operational maintenance, organisations should set new passwords for server access control, especially where there has been a restoration of the server after security incidents; (b) The Employee Data included bank account numbers and salaries. As the disclosure of such data may have a direct and significant impact on the individuals concerned, additional measures should have been adopted by Times to protect such data, for example, by encrypting such data, when storing such data in the FSS. This has been emphasised by the Commission in its Guide to Security Personal Data in Electronic Medium (Revised 20 January 2017); and (c) Times should not have used live customer data for testing purposes. As highlighted in the Commission’s Guide to Basic Data Anonymisation Techniques (Published 25 January 2018), using live personal data for testing involved risks as a development and/or test environment may be remotely accessed. Rather, Times should have used either anonymised or synthetic data, so that testing of the new functionality may be done without any risk to the personal data.4 14 As for Retention Limitation Obligation, Times admitted that the requested tool was implemented in December 2015 and the Employee Data of Red Hat’s and LIU’s Impacted Employee should have been deleted after that. In fact, Times’ SOP on software development required employees to delete personal data once project signoff has been obtained. However, in breach of the SOP, the employee who assisted in the development of the new functionality for the Payroll Software did not delete the personal data provided by TMF. No checks were conducted to ensure that the SOP was followed. Times had therefore contravened its Retention Limitation Obligation under Section 25 of the PDPA. 15 In the course of settling this decision, Times made representations proposing to take full responsibility for the Incident, and for a reduction in the quantum of financial 4 [13] of Guide to Basic Data Anonymisation Techniques. 7 Times Software Pte Ltd & Ors 2020 SGPDPC [18] penalty that the Commissioner had intended to impose. Times raised the following factors for consideration: (a) The Incident was the first data breach in Times’ 21 years of operations; (b) No damages were reported as a result of the Incident; (c) Times had improved their network security, conducted vulnerability assessments, and improved their SOPs to reduce human errors; and (d) 16 Their business had since been adversely affected by Covid-19. Times’ proposal to take full responsibility for the Incident does not absolve the other organisations that are also in breach. The PDPA imposes data protection obligations on all organisations in relation to personal data in their possession or control, and each organisation is individually responsible to comply with these obligations. 17 The other factors raised at [15(a)]-[15(d)] have were considered in mitigation. In particular, the exceptional challenges faced by businesses amid the current Covid-19 pandemic have been taken into account, bearing in mind that financial penalties imposed should not be crushing or cause undue hardship on organisations. 18 All things considered, the financial penalty imposed on Times has been reduced to $20,000 for the contravention of the Protection Obligation and Retention Limitation Obligation of the PDPA. Although a lower financial penalty has been imposed in this case, this is exceptional and should not be taken as setting any precedent for future cases. Breach by Dentons of Section 24 of the PDPA 19 Section 4(3) of the PDPA provides that an organisation has the same obligations under the PDPA in respect of personal data processed on its behalf by a data intermediary as if the personal data was processed by the organisation itself. This 8 Times Software Pte Ltd & Ors 2020 SGPDPC [18] means that both the organisation and data intermediary each have an obligation to make reasonable security arrangements to protect personal data that are in their possession or under their control. The Commission has in previous decisions stated that it is necessary for an organisation to put in place the appropriate contractual provisions with its data intermediaries to set out the obligations and responsibilities of the data intermediary to protect the organisation’s personal data, and the parties’ respective roles to protect the personal data.5 20 In this case, it is not disputed that there was no written contract between Dentons and Times regarding the processing of the Employee Data by Times. Instead, Dentons represented that it had relied on a letter issued by Times in July 2014 (the “Statement”) to protect personal data as evidence in writing of the contract. The salient terms of the Statement are reproduced below: “As a Data Intermediary, Times Software Pte Ltd has always been committed in protecting your personal data and will implement the following standard operating procedures (SOP) to ensure that we are in full compliance with the new ruling: a) All employees of Times Software Pte Ltd (“staff”) must get written consent from the customer before retrieving any personal data (such as company database or payroll related reports). The written consent must specify the identity and the purpose of usage by the applicant. b) Staff should not reveal, distribute or broadcast any personal data that are deemed confidential by the client(s) even after resignation. c) Printed copies of clients’ confidential information or personal data are not to be recycled or reused. They must be immediately shredded upon completion of usage. d) Staff are not allowed to keep or retain any customers’ personal data upon completion of its intended purpose stated in the written consent. e) Any electronic copies or duplications containing sensitive information, personal data or material which are to be sent or 5 See for example Re Cellar Door and Ors [2016] SGPDPC 22 at [15]; Re Singapore Telecommunications Limited [2017] PDPC 4 at [14]; Re Singapore Health Services Pte Ltd & Ors [2019] SGPDPC 3 at [59]. 9 Times Software Pte Ltd & Ors 2020 SGPDPC [18] received by clients via any electronic medium must be encrypted with a password only known to the staff and the client. The password must not be in the same communicated e-mail or message. It should either be advised by phone conversation, sent in via Short Messaging Service (SMS) or in a separate mailer.” [emphasis in original] 21 In the course of settling this decision, Dentons raised the following factors in relation to the Statement for consideration: (a) The Statement is a contract between Times and Dentons that is legally binding and fully enforceable. It contained three key commitments given by Times to Dentons: (i) the commitment to protect Denton’s personal data and Times’ full compliance with the PDPA; (ii) the commitment to not retain Denton’s personal data upon completion of its intended purposes, and to shred such data upon completion of use; and (iii) the commitment to encrypt all electronic copies or duplications containing sensitive information or personal data which are to be sent or received by Dentons; (b) The three commitments in the Statement mirror the obligations contained in the template clauses in the Commission’s Guide on Data Protection Clauses for Agreements in relating to Processing of Personal Data (Published 20 July 2016); (c) What is reasonable must be viewed in the context and the purposes for which personal data was being provided. Having regard to the scope and context of Denton’s engagement with Times, any other contractual obligations in addition to the Statement would be superfluous, and place an onerous and unreasonable burden on Dentons; and (d) Lastly, where an adequate level of protection had been achieved in the circumstances (of the Statement), the Commission ought not to, with the benefit of hindsight, impose onerous additional requirements on Dentons for not meeting such enhanced requirements. 10 Times Software Pte Ltd & Ors 22 2020 SGPDPC [18] Dentons’ representations that the Statement sufficed to discharge its Protection Obligation are not accepted as Dentons had overstated the effect of the Statement. While the Statement may meet the requirement of a contract evidenced in writing, it suffered from a significant flaw. The Statement omitted to cover the expected standard of protection for electronic storage of Employee Data. The commitments made by Times in the Statement pertained only to the conduct of staff, the security of physical copies of documents, and data protection (such as the need for encryption) during electronic transmission. Notably, the Statement did not specify any requirements for or include any commitments in relation to implementing security measures for the electronic storage of Employee Data, which was most relevant and paramount given that the Employee Data processed by Times was in electronic form and the Employee Data handed over by Dentons to Times was stored electronically in the FSS as mentioned at [6]. This was a serious omission of scope, which left the standard of protection of a significant volume of electronic Employee Data unaccounted for. 23 The data protection commitments in the Statement were incomplete and could not reasonably be relied on by Dentons as a security arrangement to protect the Employee Data that was provided to Times. 24 Contrary to Dentons’ representations, the requirement for an organisation to put in place contractual provisions to ensure its data intermediary will protect personal data is neither onerous nor unreasonable. In this regard, the Commission’s Guide on Data Protection Clauses for Agreements Relating to the Processing of Personal Data (Published 20 July 2016) sets outs sample clauses that an organisation may adapt to suit its needs. This is not an onerous process, and would not incur significant costs. In this case, the Statement that was introduced into the ongoing contractual relationship is sufficient written evidence of the data processing contract but it suffered from a significant defect in scope as explained at [22] above. 25 As for Dentons’ representations that the Commission should not use the benefit of hindsight to impose additional requirements on organisations, the requirement for an organisation to ensure that its written contract with its data intermediary clearly 11 Times Software Pte Ltd & Ors 2020 SGPDPC [18] specifies the data intermediary’s obligation to protect personal data is not new. As an illustration, that requirement was referred to in an earlier version of the Commission’s Advisory Guidelines on Key Concepts in the PDPA (issued in September 2013), approximately two years before Dentons had provided its Employee Data to Times for processing. 26 For the above reasons, the finding that Dentons had contravened the Protection Obligation in failing to put in place the appropriate contractual provisions with Times for the protection of their Employee Data was maintained. After taking into account the relevant mitigating and aggravating factors listed at [44] below, it was decided that a warning to Dentons for the breach would suffice in this case. Breach by TMF of Section 24 of the PDPA 27 TMF was a data intermediary of Red Hat and LIU as it was engaged to provide payroll services which involved the processing of Red Hat’s and LIU’s Employee Data. As a data intermediary, TMF was subject to the Protection Obligation set out at Section 24 of the PDPA and was required to put in place reasonable security arrangements to protect Red Hat’s and LIU’s Employee Data in its possession or under its control. What the “reasonable security arrangements” entail will depend on the context. 28 Based on the Commission’s preliminary findings, it appeared that subsequent to its engagement as Red Hat’s and LIU’s data intermediary, TMF had outsourced to Times the processing of Red Hat’s and LIU’s Employee Data for payroll services. In this scenario, Times was not only a data intermediary of TMF, but may also be referred to as a “subsidiary data intermediary” of Red Hat and LIU. 29 To elaborate, the term “subsidiary data intermediary” may be used to describe an organisation who is a sub-contractor to a data intermediary, and who is subcontracted to carry out data processing activities that are directly related and necessary to what the said data intermediary is supposed to undertake for an organisation (analogous to a data controller). As highlighted above, Times would be a “subsidiary data intermediary” of Red Hat and LIU if TMF had outsourced to Times the 12 Times Software Pte Ltd & Ors 2020 SGPDPC [18] processing of Red Hat’s and LIU’s Employee Data for payroll services, because TMF was supposed to have performed these tasks in the contract TMF had with Red Hat and LIU. 30 Subsequently, TMF clarified in its representations to the Commission’s preliminary findings that it did not sub-contract to Times any processing of Red Hat’s and LIU’s Employee Data for payroll services. Instead, it had provided Red Hat’s and LIU’s Employee Data to Times for the purposes of a one-time data migration exercise. As the data migration in this case was a different set of processing activity unrelated to the payroll services that Red Hat and LIU had engaged TMF to provide, it would not be appropriate to refer to Times as a “subsidiary data intermediary” of Red Hat and LIU. 31 Although the term “subsidiary data intermediary” may be used to describe the position the sub-contractor is in vis-à-vis the data controller (ie, it is a “subsidiary data intermediary” of the data controller), the use of such a term is simply a convenient and informal label to describe such sub-contractors in the context of data processing where subcontracting is common. It has no legal implications; in particular, it does not mean that the data controller here is responsible for its subsidiary data intermediary in the same way as it does for its primary data intermediaries. This is because in many scenarios, the data controller may not even be aware that its primary data intermediary had engaged a sub-contractor, and hence it is in no position to influence its subsidiary data intermediary. Instead, in situations where there are multiple layers of subcontracting and sub-processing of personal data, there is a separate data controller and data intermediary relationship in each layer. The scope of data processing outsourced in each layer of sub-contracting is determined by the relevant contract which should also set out the data controller’s and data intermediary’s respective obligations to protect the personal data. Therefore, even if Times was regarded as Red Hat’s and LIU’s “subsidiary data intermediary” (not actually so in this case for the reason set out in the preceding paragraph), Red Hat and LIU would not be responsible for Times as if they were Times’ data controller for the purposes of the PDPA. Times’ data controller here would be TMF solely. 13 Times Software Pte Ltd & Ors 32 2020 SGPDPC [18] Indeed, TMF’s role as Times’ data controller and Red Hat’s and LIU’s data intermediary meant that TMF was subject to the Protection Obligation in putting in place “reasonable security arrangements”, such as contractual mechanisms with Times, to ensure that Times had the necessary safeguards to protect the Employee Data. 33 In this regard, it is not disputed that there was no written contract between TMF and Times regarding the processing of the Employee Data. TMF was therefore found in breach of the Protection Obligation in the Preliminary Decision. 34 In the course of settling this decision, TMF made representations disputing the preliminary finding that it had breached the Protection Obligation, raising the following factors for consideration: (a) TMF had conducted annual vendor assessments with Times, and Times had confirmed in those assessments that it had a formal data disposal policy in place, which had led TMF to incorrectly believe that none of the Employee Data was retained by Times. In the circumstances, it would not be reasonable to expect TMF to conduct an invasive audit of Times’ IT system to verify that the Employee Data was absent; and (b) TMF did not ask Times to retain and use the Employee Data for the development of a new functionality within the Payroll Software. Times had done do without TMF’s authorisation, and was not acting as TMF’s data intermediary in doing so. Accordingly, TMF should not be held responsible for Times secret retention of the Employee Data. 35 While TMF’s conduct of the annual vendor assessments is a mitigating factor that is taken into account, it does not suffice to discharge TMF’s Protection Obligation. The annual vendor assessments would only assist to check that Times had not retained the Employee Data unnecessarily. However, it bears repeating here that TMF had not entered into any contract with Times with respect to Time’s processing of Red Hat’s and LIU’s Employee Data on TMF’s behalf. This means that the purpose and 14 Times Software Pte Ltd & Ors 2020 SGPDPC [18] scope of the processing to be undertaken by Times, as well as Times’ obligation to protect the relevant Employee Data, were not clearly set out in the first place. 36 On this note, the grounds for finding that TMF had breached the Protection Obligation is primarily due to TMF’s failure to put in place the necessary contractual provisions requiring Times to protect Red Hat’s and LIU’s Employee Data prior to the transmission of the data during the one-time data migration exercise. Hence, it is not necessary to make a finding on whether Times had used the Employee Data for the development of the new functionality tool. As mentioned at [4] above, TMF disputes this account and there was insufficient contemporaneous evidence to support either party’s version of events. 37 Having carefully considered the facts of the case, the finding that TMF had contravened the Protection Obligation was maintained. After taking into account the relevant mitigating and aggravating factors listed at [44] below, it was determined that a warning to TMF for the breach would suffice in this case. No Breach by Red Hat and LIU 38 For Red Hat and LIU, the question to be determined is whether they had taken “reasonable security arrangements” to protect their Employee Data when they provided the Employee Data to TMF for processing. 39 Red Hat and LIU had both entered into a written contract with TMF for the processing of their Employee Data. Both contracts were similarly worded and imposed a general obligation on TMF to comply with the “applicable law”, with no express reference to compliance with the PDPA. Both Red Hat and LIU were found to have contravened the Protection Obligation in the Preliminary Decision because in addition to an “applicable law” clause, they ought to have put in place more detailed contractual provisions setting out TMF’s obligations to protect the Employee Data (which included bank account and salary information). 15 Times Software Pte Ltd & Ors 40 2020 SGPDPC [18] In the course of settling this decision, Red Hat made representations disputing the preliminary finding that it had breached the Protection Obligation, and raised the following factors for consideration: (a) Although the contract between Red Hat and TMF imposed only a general obligation on TMF to comply with the “applicable law”, there should be no ambiguity that the applicable data protection law is the PDPA given that both Red Hat and TMF are incorporated in Singapore; and (b) The contract between Red Hat and TMF had to be read together with the Master Services Agreement (“MSA”) between their parent companies. The MSA contained two pertinent clauses on data protection: “TMF and its Affiliates shall use at least the same degree of care to protect the Confidential Information of Client and its Affiliations from unauthorised disclosure or access that TMF and its Affiliates use to protect its Confidential Information but not less than reasonable care” (Clause 10.4 of the MSA); and “[T]he processing and global transmission of Data shall comply with Applicable Law which includes among others the binding corporate rules of TMF on international data transfers” (Clause 11.2 of the MSA). 41 The provisions in the MSA meant that TMF was contractually bound to protect the Employee Data of Red Hat with the same standard of care as its own data, and in any case, not less than reasonable care. TMF’s internal data protection policies are therefore relevant in assessing the standard of protection that it was contractually required to put in place. In this regard, TMF’s: (i) Personal Data Protection Policy; (ii) General Data Protection Regulation Statement; and (iii) Binding Corporate Rules for processing customer data set out comprehensive requirements on data protection. 42 The inclusion of such terms in the contracts between TMF and Red Hat are adequate to satisfy the “reasonable security arrangements” requirement in Section 24 16 Times Software Pte Ltd & Ors 2020 SGPDPC [18] of the PDPA. Accordingly, Red Hat had not contravened its obligations under Section 24 of the PDPA. 43 Similarly, the contract between LIU and TMF, read together with the MSA also incorporated TMF’s Personal Data Protection Policy, General Data Protection Regulation statement and Binding Corporate Rules for processing customer data. For the same reasons set out at [40] and [41] above, it follows that the terms in the contracts between TMF and LIU are adequate to satisfy the “reasonable security arrangements” requirement in Section 24 of the PDPA. Accordingly, LIU had also not contravened its obligations under Section 24 of the PDPA. The Commissioner’s Directions 44 In determining the directions to be imposed on Times, Dentons, and TMF under Section 29 of the PDPA, the following factors were taken into account: (a) In respect of Times: Mitigating Factors (i) It has implemented remedial actions to address the deficiencies that caused the Incident; and (ii) It was cooperative in the course of investigation and had provided prompt responses to the Commission’s requests for information; and Aggravating Factor (i) The Employee Data was of a sensitive nature, and should have warranted more careful processing. (b) In respect of Dentons: Mitigating Factors 17 Times Software Pte Ltd & Ors (i) 2020 SGPDPC [18] The Employee Data was provided to Times for a one-time transaction, and the processing by Times was not expected to be of an ongoing nature; (ii) It had voluntarily reported the breach; (iii) It had not directly caused the Incident; (iv) It had implemented remedial actions to address the Incident; and (v) It had fully cooperated with the Commission in its investigations and had provided prompt responses to the Commission’s requests for information; and Aggravating Factor (i) The personal data which was subject to the Incident included bank account and/or salary information which ought to have been protected to a higher standard. (c) In respect of TMF: Mitigating Factors (i) The Employee Data was provided to Times for a one-time transaction, and the processing by Times was not expected to be of an ongoing nature; (ii) It had acted responsibly in conducting annual vendor assessments of Times; (iii) It had not directly caused the Incident; (iv) It had implemented remedial actions to address the Incident; and 18 Times Software Pte Ltd & Ors (v) 2020 SGPDPC [18] It was cooperative in the course of investigation and had provided prompt responses to the Commission’s requests for information; and Aggravating Factor (i) The personal data which was subject to the Incident included bank account and salary information which ought to have been protected to a higher standard. 45 To summarise, the Commissioner directed: (a) Times to pay a financial penalty of $20,000 within 30 days from the date of this direction, failing which interest at the rate specified in the Rules of Court in respect of judgment debts shall accrue and be payable on the outstanding amount of such financial penalty until the financial penalty is paid in full; 46 (b) A warning to be given to Dentons in lieu of a financial penalty; and (c) A warning to be given to TMF in lieu of a financial penalty. No further directions are necessary given the remediation measures already put in place by the organisations involved. MICHELLE YAP ASSISTANT COMMISSIONER FOR COMMISSIONER FOR PERSONAL DATA PROTECTION 19 ",Financial Penalty,976a574a38eb0225fbf7a43d418a4b5c6717efc8,"[""pdf-content"",""timestamp"",""decision"",""pdf-url"",""tags"",""nature"",""url"",""title"",""date"",""description""]" 2023-10-01T11:02:10+08:00,fbd32491db44d3d0c97aa12a99cefd61ec954264,119,119,1,952,"A financial penalty of $34,000 was imposed on Globalsign.in for failing to put in place reasonable security arrangements to protect the personal data supplied by its clients. Globalsign.in, which sends mass marketing emails on behalf of its clients to their respective customers, was also found to be holding personal data which was no longer necessary for legal or business purposes.","[""Protection"", ""Retention Limitation"", ""Financial Penalty""]",2020-01-09,https://www.pdpc.gov.sg/-/media/Files/PDPC/PDF-Files/Commissions-Decisions/Decision--MSIG-Insurance-Singapore-Pte-Ltd--191119.pdf,"Protection, Retention Limitation",Breach of the Protection and Retention Obligations by Globalsign.in Pte Ltd,https://www.pdpc.gov.sg/all-commissions-decisions/2020/01/breach-of-the-protection-and-retention-obligations-by-globalsignin-pte-ltd,2020-01-09,"PERSONAL DATA PROTECTION COMMISSION [2019] SGPDPC 43 Case Nos. DP-1708-B1066; DP-1708-B1086 In the matter of an investigation under section 50(1) of the Personal Data Protection Act 2012 And (1) (2) MSIG Insurance (Singapore) Pte Ltd Globalsign.in Pte Ltd …Organisation(s) DECISION Re MSIG Insurance (Singapore) and another [2019] SGPDPC 43 (1) MSIG Insurance (Singapore) Pte Ltd (2) Globalsign.in Pte Ltd [2019] SGPDPC 43 Mr Tan Kiat How, Commissioner – Case Nos. DP-1708-B1066; DP-1708-B1086 19 November 2019 Introduction and Material Facts 1. MSIG Insurance (Singapore) Pte Ltd (“MSIG”) notified the Personal Data Protection Commission (the “Commission”) on 22 August 2017 that the mass emailing system of its service provider, Globalsign.in Pte Ltd’s (“GSI”), had been accessed without authorisation and used to send spam emails (the “Incident”) to 149,172 email addresses which belonged to MSIG’s customers (“Impacted Customers”). 2. GSI runs and hosts an email marketing platform known as “Global2Mail Online Marketing Web Application” (the “G2M” platform). GSI uses the G2M platform to send mass marketing emails to email addresses supplied by its clients. 3. MSIG, an insurance provider, had engaged GSI to send marketing emails to its customers via the G2M platform. For this purpose, MSIG and GSI had entered into an agreement dated 1 October 2013. An addendum to the said agreement was entered into on 16 May 2014 to take into consideration the obligations of both organisations under the Personal Data Protection Act 2012 (the “PDPA”). GSI’s services were renewed by MSIG, with MSIG and GSI entering into a new agreement on 1 August 2017 (the “Agreements”). 4. MSIG provided GSI with a list of email addresses of its customers each time an email marketing campaign was launched. For some of the email addresses, MSIG also provided the first and last names to GSI and these would be captured in the G2M platform. According to MSIG, the email addresses and names (where applicable) provided to GSI were password-protected. 2 Re MSIG Insurance (Singapore) and another 5. [2019] SGPDPC 43 Although no specific retention period for the email addresses provided by MSIG to GSI was stated in the Agreements, MSIG required GSI to delete and purge the email addresses and other personal data from its server after each marketing campaign. This is seen from emails sent by MSIG to GSI on 9 December 2016, 30 May 2017 and 5 June 2017 where MSIG asked GSI to confirm that it had purged the email addresses which had been provided by MSIG to GSI for specific marketing campaigns. 6. On 18 August 2017, the administrator account of the G2M platform was accessed without authorisation. By accessing the administrator account, the intruder was also able to access the email addresses and, in certain instances, names of individuals (the “Compromised Data”) that were stored on the G2M platform. 7. On 19 August 2017, the G2M platform sent spam emails to 359,364 email addresses that were stored on the G2M platform (the “Spam Emails”). 149,172 of these email addresses were email addresses of MSIG’s Impacted Customers (which MSIG had provided to GSI) and 201,192 were email addresses of customers (“Other Impacted Individuals”) provided to GSI by three of GSI’s other clients for use with the G2M platform. Each of the Spam Emails: (a) purported to provide tips on how to win a lottery; (b) contained a link under “clickbank.net” that redirected its users to a video on “lotterydominator.com”; (c) appeared be sent from “MSIG Insurance” with the address “service@sg.msigasia.com”; 8. (d) was only sent to one email address; and (e) contained no other personal data other than the email address of the recipient. After MSIG informed the Commission about the Incident on 22 August 2017, MSIG and GSI jointly engaged a cyber-security consultancy to investigate into the data breach. 9. The cyber-security consultancy’s investigations concluded that the Spam Emails did not contain phishing or malware content. It would appear that the end users who clicked on the links in the Spam Emails were simply redirected to the video on the “lotterydominator.com” website and there were no complaints from the users of any further negative consequences from clicking the links. 10. MSIG took the following remedial action after the Incident: 3 Re MSIG Insurance (Singapore) and another (a) [2019] SGPDPC 43 On 21 August 2017, MSIG posted an alert on the Spam Emails on its corporate website and Facebook page. (b) On 22 August 2017, MSIG instructed GSI to purge all email addresses and names of its customers in GSI’s database, save for those customers that were affected, as they wanted to send out an apology email; (c) FAQs were included from 28 August 2017. MSIG also instructed GSI to deactivate its email account service@sg.msig-asia.com which had been used to send the Spam Emails; (d) On 24 August 2017, MSIG worked with GSI on an email sent by the latter to all 149,172 affected MSIG customers to apologise for the breach. The email included instructions on removing any malware from the link in the Spam Email. It provided a point of contact for any queries. MSIG instructed GSI to purge the email addresses and names of its affected customers thereafter. 11. Between 21 to 30 August 2017, MSIG addressed queries from 92 customers who had been affected by the Incident. 12. Separately, GSI took the following remedial action after the Incident: (a) Blocked the Spam Email link at server level to prevent recipients being re-directed to the site; (b) Immediately disabled the compromised administrator account to ensure no data would be exported and subsequently restored the account after putting in place additional security measures; (c) Changed password to the administrator account before restoring the account and implemented two-factor authentication (2FA) for all accounts whereby users would have to key in a one-time password sent either sent to their mobile number by SMS or Google Authenticator Application; (d) Transferred the application database to a new server, hosted in Amazon Web Services in Singapore in an encrypted database; (e) Enforced HTTPS so that all traffic from end-users to GSI’s website would be encrypted; (f) Improved logging of access, whereby I.P. addresses used to access G2M would be properly logged at application server level, and added logging of web attacks that had been blocked by the server firewall; and (g) Engaged a consulting company to assist GSI in implementing policies that meet the ISO 27001 standards. 4 Re MSIG Insurance (Singapore) and another [2019] SGPDPC 43 Findings and Basis for Determination Whether the Compromised Data included Personal Data 13. The personal data found in the Compromised Data included (i) the first and last names of some MSIG customers, (ii) the email addresses of those customers (i.e. which were stored with the names of the customers) and (iii) the email addresses of other customers which contained their full or partial names (the “Compromised Personal Data”). In relation to the latter set of email addresses, as set out in Re Credit Counselling [2017] SGPDPC 18 at [9], email addresses are personal data if they disclose the full name or partial name of individuals which allows for the identification of such individuals. 14. The Compromised Data also included other email addresses which were not linked to, or did not contain, the name of the customer (“Other Email Addresses”). It was also noted in Re Credit Counselling (at [10]) that an email address coupled with other information which enables identification of an individual, such as information obtained from a search on the Internet, is personal data. Whether MSIG or GSI had breached section 24 of the PDPA 15. The main issue in this case is whether MSIG and GSI had done enough to protect the Compromised Personal Data which was in their possession or under their control. Section 24 of the PDPA requires organisations to make reasonable security arrangements 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 or similar risks. 16. As MSIG had provided the personal data relating to MSIG’s Impacted Customers to GSI in order to make use of the G2M platform for its purposes, both MSIG and GSI are required to comply with section 24 of the PDPA. However, the scope of their respective obligations under that section differs. In addition, GSI would be required to comply with section 24 in respect of all Compromised Personal Data (that is, personal data relating to MSIG’s Impacted Customers and the Other Impacted Customers). 17. In relation to MSIG, as they had engaged GSI to send marketing emails using the G2M platform, the scope of their obligations would relate to the arrangements MSIG 5 Re MSIG Insurance (Singapore) and another [2019] SGPDPC 43 established in order to ensure that GSI protected the personal data in the G2M platform. In respect of MSIG, the Commissioner found that MSIG had complied with its obligations under section 24 of the PDPA for the following reasons: (a) MSIG imposed security requirements on GSI under the Agreements to protect personal data. An express clause in the Agreements provides that GSI shall “implement sufficient and appropriate measures to guard against accidental or unauthorised access, collection, use, disclosure, misuse, loss, destruction, deletion, alteration, modification and processing of the Personal Data”; (b) MSIG also had the right under the Agreements to inspect and audit GSI; and (c) There was evidence that MSIG followed through with these contractual obligations with operational processes, for example, there were emails showing that MSIG required GSI to purge the personal data it provided after each marketing campaign. In this regard, MSIG had sent emails to GSI on at least three separate occasions between December 2016 and June 2017 asking GSI to purge email addresses provided by MSIG from its system. 18. In relation to GSI, as GSI was operating the G2M platform, it was required to put in place reasonable security arrangements in the form of technical or administrative measures to protect the personal data in the G2M platform. In this regard, the Commissioner found that GSI had not made the appropriate security arrangements and was therefore in contravention of section 24 of the PDPA for the following reasons: (a) GSI had not implemented administrative or technical measures to require a regular change to the passwords to its administrator and client accounts in the G2M platform. In addition, GSI recognised that there was a risk that if accounts of staff who had left the employment of GSI were not disabled, these former staff may continue to have access to its applications. The need for an effective password expiry mechanism has been discussed in past decisions such as Re Orchard Turn Developments Pte Ltd [2017] SGPDPC 12; (b) When the administrator account changed hands, there were no logs to record the fact that passwords had been changed; (c) Users were encouraged to choose strong passwords but GSI did not enforce any password strength requirements. The need for strong passwords is discussed in Re Singhealth and anor [2019] SGPDPC 3; (d) All the users of the administrator account shared the same administrator account and the same set of login credentials. This made it difficult to determine which staff had accessed the account or identify who had made changes to the system 6 Re MSIG Insurance (Singapore) and another [2019] SGPDPC 43 during each log-in session. Re Orchard Turn Developments Pte. Ltd. [2017] SGPDPC 12 explains why the sharing of administrator account credentials can give rise to an increased risk of data breaches; (e) It was found that no security scans were carried out over the 12 months before the Incident. Security scans are important in light of the type of personal data likely to be held by MSIG as an insurer. In Re Courts (Singapore) Pte Ltd [2019] SGPDPC 4, the Respondent’s lack of regular testing and scanning for security issues were taken into account as factors to find a breach of section 24 of the PDPA. (f) GSI claimed that it had complied with MSIG’s express instructions to “delete and purge the data after each marketing campaign”. However, this cannot be true as the G2M platform still retained at least 149,172 email addresses provided by MSIG which had been used in this Incident. Whether GSI had complied with section 25 of the PDPA 19. As noted above, it appeared that GSI had not deleted 149,172 email addresses provided by MSIG after the relevant marketing campaigns were completed and notwithstanding email reminders from MSIG. Section 25 of the PDPA requires an organisation to cease retaining documents containing personal data, or to remove the means by which the personal data can be associated with particular individuals, as soon as it is reasonable to assume that: (a) The purpose for which that personal data was collected is no longer being served by retention of the personal data; and (b) 20. Retention is no longer necessary for legal or business purposes. As GSI was required to delete email addresses provided by MSIG once the relevant marketing campaigns were completed, GSI ipso facto ceased to have any purpose for retaining the email addresses in the G2M platform once the relevant marketing campaigns were completed. Accordingly, the Commissioner found that GSI was in contravention of section 25 of the PDPA. GSI’s Representations 21. After the Commissioner’s preliminary decision was issued to MSIG and GSI, GSI submitted representations in relation to the quantum of financial penalty which the Commissioner proposed to impose in relation to its breach of section 24 of the PDPA 7 Re MSIG Insurance (Singapore) and another [2019] SGPDPC 43 and against the Commissioner’s determination that it had breached section 25 of the PDPA. However, GSI did not disagree with, or make any representations relating to, the Commissioner’s findings that it had breached section 24 of the PDPA. 22. First, GSI raised the following points as to why certain numbers of email addresses should not be taken into consideration in determining the number of affected individuals: (a) 4,488 of the email addresses which were stored on the G2M platform and which received the Spam Emails did not include the name or any other identifier of the individuals; (b) approximately 12,000 Spam Emails sent to the email addresses stored on the G2M platform had bounced; (c) approximately 145,338 Spam Emails were sent to GSI’s overseas based clients; and (d) Only 18,113 recipients opened the Spam Emails and, of these, only 339 recipients clicked on the link contained within the Spam Emails. 23. In relation to sub-paragraph (a) above, the Commissioner accepts GSI’s representation and has taken the reduced number of impacted individuals into account in determining the financial penalty quantum specified below. In relation to (b), the fact that the Spam Emails bounced is not conclusive that the email addresses were invalid as the emails may have bounced due to other reasons, such as the recipient’s email inbox being full at that time. In relation to (c), GSI is required to protect personal data in its possession or under its control and it is immaterial whether the relevant individuals were resident in Singapore or overseas. Finally, in relation to (d), it has already been taken into account that there was no harm suffered by the recipients (see paragraph 32 below) and the Organisation’s point at (d) above does not provide further mitigation of the Organisation’s breach 24. Secondly, GSI represented that MSIG had access to the G2M platform and could exercise functions such as verifying the content of the platform, creating and sending out email campaigns and deleting content and emails. However, the fact that MSIG had access to the G2M platform does not absolve GSI from its obligations under the PDPA. The fact remains that MSIG had engaged GSI to send marketing emails using the G2M platform and GSI was obliged under the PDPA to protect the personal data that was in its possession or under its control for the purposes of this engagement. Furthermore, MSIG had specifically instructed GSI to delete the email addresses after each marketing campaign and this is something that GSI is contractually bound to do. 8 Re MSIG Insurance (Singapore) and another 25. [2019] SGPDPC 43 Thirdly, GSI raised the following additional points as mitigating factors for the Commission’s consideration: (a) GSI had been fully cooperative during the Commission’s investigations; (b) There was no evidence of exfiltration, further disclosure or modification of the Compromised Data; (c) The Spam Emails sent to the Impacted Customers did not contain any personal data; (d) There was no evidence of actual loss or damage suffered by any of the Impacted Customers; (e) GSI has also sent an email notification to all Impacted Customers of the Spam Emails; (f) GSI has in place internal data protection policies prior to the Incident; and (g) GSI has since taken further steps to tighten and strengthen its data protection policies and mechanisms, including sending additional employees for further PDPA training, engaging external vendors to conduct advisory sessions and gap analysis, completing a surveillance audit and implementing various internal programs and workshops to promote data responsibility. 26. The matters in sub-paragraphs (a) to (d) above had already been taken into consideration in determining the financial penalty (see paragraph 32 below). With regards to (f), organisations are required under the PDPA to implement policies and practices necessary for them to meet their obligations under the PDPA, and mere compliance with the PDPA is not a mitigating factor. 27. GSI’s notification of the affected individuals is a relevant consideration and the further steps set out in (g) are relevant mitigating factors and the quantum of the final financial penalty set out below has been reduced. 28. Fourthly, GSI sought to compare the facts of this case with prior decisions such as Re Avant Logistic Service Pte Ltd [2019] SGPDPC 28, Re AIA Singapore Private Limited [2019] SGPDPC 20, Re InfoCorp Technologies Pte Ltd [2019] SGPDPC 17, Re Option Gift Pte Ltd [2019] SGPDPC 10 and Re AIG Asia Pacific Insurance Pte Ltd & Toppan Forms (S) Pte Ltd [2019] SGPDPC 2. It should be borne in mind, that none of these cited cases dealt with a similar scale of breach and cannot be relied upon to argue for a lower financial penalty. 9 Re MSIG Insurance (Singapore) and another 29. [2019] SGPDPC 43 GSI also made the following representations against the Commissioner’s determination that it had breached section 25 of the PDPA: (a) GSI sent an email to MSIG on 5 June 2017 confirming the deletion or purging of data from previous campaigns. This email read as follows: “Yes, we are in the midst of purging the most recent campaigns. The older ones have been purged.” The above email does not confirm that all completed campaigns have been purged, and only indicated that GSI was in the midst of doing so, and shows that some email addresses from recently concluded campaigns had not been removed from the system. This is, at best, evidence that GSI was trying to purge customer data after each campaign, but was not particularly prompt. (b) GSI asserted that MSIG was an active client and, hence, the G2M platform retained 149,172 email addresses of MSIG’s customers even after data from previous campaigns had been purged. However, this is contrary to the evidence which shows that MSIG had requested GSI to delete all email addresses after each email marketing campaign; and GSI’s representations that it was putting in effort to do so (albeit with some delays). In the final analysis, the representations in relation to the breach of section 25 of the PDPA did not warrant a review of the Commissioner’s findings. Outcome 30. After considering the facts of this case, the Commissioner hereby directs GSI to pay a financial penalty of $34,000 within 30 days from the date of the directions, failing which interest shall be payable on the outstanding amount of such financial penalty at such rate as specified in the Rules of Court. 31. In determining the amount of the financial penalty set out above, the Commissioner recognised that not all of the 359,364 email addresses targeted by the Spam Emails in the Incident constituted personal data and it was not possible for the Commission to determine the exact number of email addresses which did constitute personal data. Nevertheless, taking into account the GSI lapses and the other facts of the case detailed 10 Re MSIG Insurance (Singapore) and another [2019] SGPDPC 43 above, the Commissioner considered that a financial penalty of $34,000 would be appropriate. 32. In coming to this decision, the Commissioner also had regard to the following mitigating factors: (a) GSI was cooperative in the course of the Commission’s investigation and had provided prompt responses to the Commission’s requests for information; (b) GSI implemented the remedial actions set out paragraphs 10 to 12 above to address the Incident quickly, including notifying the affected individuals; and (c) 33. There was no harm caused by the disclosure of the Compromised Personal Data. The Commissioner was of the view that no further directions are required given the remedial actions already taken by MSIG and GSI. YEONG ZEE KIN DEPUTY COMMISSIONER FOR COMMISSIONER FOR PERSONAL DATA PROTECTION 11 ",Financial Penalty,4c9d4905f641206cd304485dcb39659ee42e32db,"[""pdf-content"",""timestamp"",""decision"",""pdf-url"",""tags"",""nature"",""url"",""title"",""date"",""description""]" 2023-10-01T11:02:10+08:00,fbd32491db44d3d0c97aa12a99cefd61ec954264,202,202,1,952,"A financial penalty of $18,000 and directions were issued to Social Metric for leaving the personal data exposed to the world wide web via unprotected URL links; and failure to remove personal data of its clients’ customers from its website when they no longer served a legal or business purpose.","[""Protection"", ""Retention Limitation"", ""Financial Penalty"", ""Directions"", ""Information and Communications""]",2017-11-27,https://www.pdpc.gov.sg/-/media/Files/PDPC/PDF-Files/Commissions-Decisions/Grounds-of-Decision-Social-Metric-271117.pdf,"Protection, Retention Limitation",Breach of Protection and Retention Obligations by Social Metric,https://www.pdpc.gov.sg/all-commissions-decisions/2017/11/breach-of-protection-and-retention-obligations-by-social-metric,2017-11-27,"PERSONAL DATA PROTECTION COMMISSION [2017] SGPDPC 17 Case No DP-160-A712; DP-1604-A713 In the matter of an investigation under section 50(1) of the Personal Data Protection Act 2012 And Social Metric Pte Ltd … Organisation DECISION Social Metric Pte Ltd [2017] SGPDPC 17 Tan Kiat How, Commissioner — Case No DP-160-A712; DP-1604-A713 27 November 2017. Background 1 This case involves a company which, as part of its social media marketing campaigns conducted for and on behalf of its clients, created webpages containing the personal data of its clients’ customers; and subsequently failed to remove those webpages from the world wide web, even after the social media marketing campaigns were over. 2 A complaint was made to the Personal Data Protection Commission (“PDPC”) regarding the unauthorised disclosure of personal data on these webpages on the world wide web. The Commissioner undertook an investigation into the matter, and the Commissioner sets out his findings and decision on the matter below. Material Facts and Documents 3 Social Metric is a digital marketing agency that provides social media marketing services. As part of these services, Social Metric would collect personal data of its clients’ customers for various purposes, for example, as a form of customer engagement, or to analyse the customer demographics, amongst other things. Social Metric Pte Ltd 4 [2017] SGPDPC 17 For the webpages in question, Social Metric had created nine webpages (the “Webpages”) for various social media contests that Social Metric conducted for and on behalf of its clients. These Webpages were found on Social Metric’s website at https://www.socialmetric.com (the “Website”). The Webpages consisted of tables that listed out various particulars of individuals. They were created for internal administrative and client use. 5 The personal data in these nine Webpages included individuals’ names; email addresses; contact numbers; employers; occupations; date and time of registration; and other miscellaneous information including, “places to visit” (eg states in Australia), “activities” (outdoor sports), and “purpose” (eg personal growth). In particular, two out of the nine Webpages also contained the personal data (name and age) of about 155 children. The Commissioner’s investigations disclosed that such personal data was provided by the individuals directly (ie by the individual sending his or her personal data to Social Metric through Facebook’s private message function), and were not obtained from publicly available sources. 6 Based on the date and time of registration of the nine Webpages, it was observed that all the personal data contained therein, except for two individuals, were collected and disclosed before the Personal Data Protection Act 2012 (“PDPA”) came into full force on 2 July 2014 (“Appointed Day”). In respect of the two individuals, the personal data of one of the individuals (name, email address, contact number) was disclosed on 24 December 2014, while the personal data of the other individual (name and email address) was disclosed on 15 September 2015. 7 Social Metric was first informed by the Complainant of the unintended disclosure of personal data on the nine Webpages on 27 April 2016. Following 2 Social Metric Pte Ltd [2017] SGPDPC 17 the complaint made by the Complainant to the PDPC, the PDPC had also informed Social Metric about the disclosure on the Webpages in May 2016. After being informed about the Webpages, Social Metric took down three out of the nine Webpages. However, at the time of the Commissioner’s investigation, six out of the nine Webpages were still available on the world wide web. These remaining six Webpages contained the personal data of approximately 558 individuals. As at 11 July 2016, all the Webpages have been taken down. The personal data was therefore left on the Webpages for a period of at least 2 months since the time that Social Metric had first been informed of the personal data that was held on its Website until they were all completely taken down. By the Commissioner’s estimate, given that some of the marketing campaigns had ended by the Appointed Day, some of the personal data would have been left on the Webpages for more than two years after the respective events. Commissioner’s Findings and Basis for Determination Issues for Determination 8 Based on the facts, there were two main issues for determination before the Commissioner: (a) what were Social Metric’s obligations under the PDPA with respect to the personal data found on the Webpages that were exposed on the internet; (b) whether Social Metric complied with these obligations. Specifically, (i) whether Social Metric complied with its Retention Limitation Obligation under section 25 of the PDPA when it 3 Social Metric Pte Ltd [2017] SGPDPC 17 retained the personal data of its clients’ customers even after the social media marketing campaigns were over; and (ii) whether Social Metric has complied with its Protection Obligation under section 24 of the PDPA, given the unauthorised disclosure of personal data on the Webpages. (a) Social Metric’s obligations under the PDPA i. 9 How did the Data Protection Provisions of the PDPA apply to Social Metric? As the Webpages were created before the Data Protection Provisions of the PDPA (ie Parts III to VI of the PDPA) came into force on the Appointed Day, it is necessary to examine how Social Metric came to take on these obligations under the PDPA in respect of the Webpages. 10 Before the Appointed Day, the Data Protection Provisions of the PDPA were not in force, and hence, Social Metric was not subject to these provisions in relation to the personal data that it had processed for its clients’ social marketing campaigns. After the Appointed Day, the Data Protection Provisions under the PDPA came into force, and at such time, it became incumbent on an organisation (as in this case, Social Metric) to take proactive steps to comply with these obligations under the PDPA in respect of the existing personal data held in their possession or control, as well as any new personal data that it may come into possession or control with. 11 This means that, for example, if there were no security arrangements previously to protect the existing personal data the organisation was holding, the organisation has a positive duty to put in place security arrangements after the Appointed Day. It was not enough for the organisation to leave things status 4 Social Metric Pte Ltd [2017] SGPDPC 17 quo, if this would not enable the organisation to meet the requirements and standards of the Protection Obligation. As provided in Section 24 of the PDPA, the security arrangements must be “reasonable”. 12 What has just been described about the PDPA obligations coming into operation and applying after the Appointed Day is to be contrasted with the ‘grandfathering’ provision under section 19 of the PDPA, which also applies to personal data held by an organisation before the Appointed Day. In essence, section 19 of the PDPA allows an organisation to continue to use (but not disclose) personal data that was collected before the Appointed Day for such purposes for which the personal data was collected, without having to obtain consent under the Data Protection Provisions. As mentioned in Re Comfort Transportation Pte Ltd and another [2016] SGPDPC 17, personal data collected before the Appointed Day as business contact information could continue to be used after the Appointed Day as such. Notwithstanding the grandfathering of the purpose for usage, the organisation would have to still comply with the rest of the Data Protection Provisions. 13 From the above analysis, therefore, Social Metric has the obligation to comply with the Data Protection Provisions under the PDPA in respect of the existing personal data that were held on its Website. ii. 14 In what capacity did Social Metric take on such obligations under the PDPA? In order to determine what obligations apply to Social Metric under the PDPA, it is apposite to consider the capacity that Social Metric was in when it was carrying out the data processing activities on the personal data of its clients’ customers – ie as a data intermediary or an organisation. This is because 5 Social Metric Pte Ltd [2017] SGPDPC 17 different sets of obligations and responsibilities may apply depending on the capacity that Social Metric is in. 15 Under the PDPA, when an organisation carries out data processing activities on behalf of another, the organisation is considered a data intermediary. The PDPA obligations that would apply to a data intermediary pursuant to section 4(2) of the PDPA are limited to two obligations – the Protection Obligation and Retention Limitation Obligation. In comparison, an “organisation” under the PDPA, for which the data intermediary is performing the data processing, would be subject to the full range of obligations under the PDPA. This is so, even though the organisation may have engaged a data intermediary to implement the necessary data protection measures for the organisation. Section 4(3) of the PDPA provides that “an organisation shall have the same obligation under this Act in respect of personal data processed on its behalf and for purposes by a data intermediary as if the personal data were processed by the organisation itself”. 16 Beyond the different sets of obligations that may apply to an organisation or data intermediary, there may also be different responsibilities that an organisation or data intermediary may undertake under the PDPA. As explained in Re Smiling Orchid (S) Pte Ltd and others [2016] SGPDPC 19, in a situation where the data processing activities are carried out by the organisation’s external vendor, the organisation has a supervisory or general role for the protection of the personal data, while the data intermediary has a more direct and specific role in the protection of personal data arising from its direct possession of or control over the personal data. This means that the organisation can still be liable for a data breach for failing to meet its responsibility, even though its data intermediary was found to have its own responsibility, and vice versa. 6 Social Metric Pte Ltd 17 [2017] SGPDPC 17 In this case, at the point of collection of personal data, Social Metric was carrying out the collection on behalf of its clients for the marketing campaigns, and was thus acting as a data intermediary for its clients. Next, with regard to Social Metric posting the personal data of its clients’ customers on the Website, that, too, was done in the capacity as a data intermediary. The Website was put up for the purposes of the marketing campaigns of Social Metric’s clients. It was when the marketing campaigns had ended, and Social Metric had held on to the personal data (which was still posted on the Website) for a longer period than was reasonable, that Social Metric can no longer be considered a data intermediary in relation to such activities. 18 There are two main reasons for this position. First, the social marketing campaigns were already over, and both Social Metric and its clients had no further purpose in retaining the personal data on the Website. Social Metric cannot be said to be “[processing] personal data on behalf of” its clients by the protracted retention of the personal data on its Website. Indeed, as mentioned above, based on the Commissioner’s estimate, some of the personal data was kept on its Website for more than two years. Accordingly, at some point in time, Social Metric was no longer a data intermediary within the definition of this term under the PDPA. Instead, Social Metric was now acting on its own accord in relation to the personal data that it held, and had taken on the full responsibility of protecting such personal data. Second, Social Metric had a standard operating procedure (“SOP”) to dispose of the personal data after the marketing campaigns in its contract for service with its clients had ended. As far as the clients were concerned, it was reasonable to expect Social Metric to carry out the disposal upon the completion of the marketing campaigns, and there was no evidence that Social Metric’s clients were aware that Social Metric had failed to dispose of the personal data. In the premises, it would not be logical nor fair if the PDPA imposes a continuing obligation on Social Metric’s clients 7 Social Metric Pte Ltd [2017] SGPDPC 17 to protect the personal data. Since Social Metric had failed to carry out what it was supposed to do (ie to dispose of the personal data after the marketing campaigns), it bears the risk for whatever happens to the personal data that was held in its hands after the marketing campaigns were over. 19 Social Metric had therefore assumed the full data protection responsibilities of an “organisation” under the PDPA after the end of the marketing campaigns. This is a position that has been adopted by foreign data protection authorities as well. iii. 20 Foreign authorities on the issue of a data intermediary taking on responsibilities of an organisation The foreign data protection authorities have taken the position that a data processor, which was originally engaged to perform data processing activities for or on behalf of a data controller, could subsequently take on the data protection responsibilities of a data controller under certain circumstances, for example, where the data processor uses the personal data for its own unauthorised purposes, or for additional purposes not envisaged by the data controller, or for its own benefit. 21 According to the guidance issued by the UK’s Information Commissioner’s Office, Data controllers and data processors: what the difference is and what the governance implications are (“ICO guidance”), a data processor may become a data controller in its own right, albeit to a limited 8 Social Metric Pte Ltd [2017] SGPDPC 17 extent, when, for example, the processor breaks the agreement with its data controller. The ICO guidance provides that:1 “65. A data processor will have access to the personal data held by the controller or controllers it provides its services to but it cannot have any of its own data controller responsibilities for that data. However, in certain situations this may change and it will become a data controller in its own right if only to a limited extent. … 67. If a data processor breaks the agreement with its data controller, for example by using the data for its own unauthorised purposes, then it will also take on its own data controller responsibilities. This includes the duty under the first data protection principle to process, including to obtain, personal data fairly and lawfully. Where a data processor takes the personal data the controller has entrusted it with but breaks the terms of its contract by using the data for its own purposes, it is likely to be in breach of the first principle and the ICO could take enforcement action against it…” [Emphasis added.] 22 Similarly, in the EU, the European Commission has issued Opinion 1/2010 on the concepts of “controller” and “processor” which describes a scenario where a data processor which conducts marketing activities may be considered to be a data controller and become subject to data protection obligations:2 “In these cases - where there is a good definition of purposes, but little or even no guidance on technical and organizational means - the means should represent a reasonable way of 1 U.K., Information Commissioner’s Office, Data controllers and data processors: what the difference is and what the governance implications are (6 May 2014) at paras. [65], [67]. 2 E.U., European Commission, Art. 29 Data Protection Working Party, Opinion 1/2010 on the concepts of “controller” and “processor” (16 Feb 2010) at p.14. 9 Social Metric Pte Ltd [2017] SGPDPC 17 achieving the purpose(s) and the data controller should be fully informed about the means used. Would a contractor have an influence on the purpose and carry out the processing (also) for its own benefit, for example by using personal data received with a view to generate added-value services, it would be a controller (or possibly a joint controller) for another processing activity and therefore subject to all the obligations of the applicable data protection law. Example No. 3: Company referred to as data processor but acting as controller Company MarketinZ provides services of promotional advertisement and direct marketing to various companies. Company GoodProductZ concludes a contract with MarketinZ, according to which the latter company provides commercial advertising for GoodProductZ customers and is referred to as data processor. However, MarketinZ decides to use GoodProducts customer database also for the purpose of promoting products of other customers. This decision to add an additional purpose to the one for which the personal data were transferred converts MarketinZ into a data controller for this processing operation. The question of the lawfulness of this processing will still be assessed in the light of other Articles (6-8).” [Emphasis added.] 23 This means that where a data processor has an influence on the purpose of the processing, and carries out a separate processing activity which is different from the purpose that the data controller envisaged or which is for the data processor’s own benefit, then the data processor could be considered a data controller for that separate processing activity. 24 Whilst Singapore does not have the concept of a “data controller” or a “data processor” in its data protection regime, these terms taken from the UK’s Data Protection Act 1988 and the EU Directive 95/46/EC do bear similarities to the concept of “organisation” and “data intermediary” respectively in the PDPA. As such, the Commissioner is of the view that the general principles mentioned above are useful and supportive of the position that the Commissioner has taken. 10 Social Metric Pte Ltd [2017] SGPDPC 17 (b) In this case, Social Metric’s compliance with its Retention Limitation and Protection Obligations comes into focus 25 Accordingly, while Social Metric had initially held the de facto role of a data intermediary (before the Appointed Day) during the marketing campaigns, Social Metric had subsequently taken on the role of an “organisation” when it held on to the personal data on its Website after the marketing campaigns with its clients were over. 26 In this case, the pertinent issues relate to Social Metric’s compliance with its Protection and Retention Limitation Obligations. This is because the nature of the breach and the subject of complaint in this case relate to (a) Social Metric’s failure to protect the personal data on the Webpages from unauthorised access; and (b) Social Metric’s failure to remove personal data of its clients’ customers from its Website in accordance with its SOP or a reasonable period thereafter justifiable for legal or business purposes (“the tail period”). These are obligations that are common between Social Metric as data intermediary or as organisation. Had the period of retention been shorter, and Social Metric stayed as a data intermediary, its alleged misconduct would have been analysed as breaches of the Retention Limitation and Protection Obligations qua data intermediary. Where in this case, a considerable period has passed, and the data intermediary has morphed into an organisation, it is not meaningful to split hairs and analyse part of the period in which Social Metric had held on to the data as a breach of a data intermediary’s Retention Limitation and Protection Obligations while analysing the rest of this period as a breach of an organisation’s Retention Limitation and Protection Obligations. With the effluxion of time that Social Metric had held on to the data, there was nothing to separate Social Metric’s responsibilities under the Retention Limitation and Protection Obligations from that of a data intermediary or an organisation – 11 Social Metric Pte Ltd [2017] SGPDPC 17 Social Metric ultimately took on the role and responsibility as an “organisation” under the PDPA for the protection of personal data. The entire period in excess of “the tail period” should be analysed as a breach of an organisation’s Retention Limitation and Protection Obligations. 27 We turn now to the assessment of whether or not Social Metric has complied with its Retention Limitation and Protection Obligations. i. 28 Whether Social Metric has complied with the Retention Limitation Obligation Under the Retention Limitation Obligation, an organisation is obliged to cease retaining its documents containing personal data, or remove the means by which the personal data can be associated with particular individuals, as soon as it is reasonable to assume that: (a) the purpose for which the personal data was collected is no longer served by retaining the data; and (b) retention is no longer necessary for legal or business purposes. As limbs (a) and (b) of section 25 of the PDPA are conjunctive, this means that if the organisation still has purposes for retaining the personal data under either limb (a) or limb (b) of section 25 of the PDPA, the organisation is allowed to retain such personal data. 29 On the facts of this case, Social Metric held on to the personal data even though the marketing campaigns were over. Under limb (a) of section 25 of the PDPA, the purpose for which the personal data was collected was no longer being served by retention of the personal data. Additionally, based on the evidence in this matter, there was nothing to indicate that Social Metric had any legal or business purpose under limb (b) of section 25 of the PDPA for keeping the personal data either. Since the purpose of retention as a data intermediary was no longer valid, retention as an organisation is all the more indefensible. Accordingly, Social Metric has failed to show that it had any purpose for 12 Social Metric Pte Ltd [2017] SGPDPC 17 retaining personal data pursuant to limbs (a) and (b) of section 25 of the PDPA, and it is therefore in breach of section 25 of the PDPA. ii. 30 Whether Social Metric has complied with the Protection Obligation As explained above at paragraphs 25 to 26 above, Social Metric has an obligation to protect personal data under the Protection Obligation as an organisation under the PDPA (pursuant to Section 24 of the PDPA). Social Metric had taken on the role of an “organisation” when it held on to the personal data on its Website after the marketing campaigns with its clients were over, and it was in such a capacity that it had the duty to protect the personal data in its possession or control after the Protection Obligation came into force on the Appointed Day. 31 The Commissioner finds that Social Metric failed to comply with its Protection Obligation. Social Metric had failed to limit access to the Webpages, and had left the personal data on the Webpages exposed to the world wide web. There were no security or access controls on the Website or on any of the Webpages, such as a password protection. Any member of the public could have accessed the personal data of the clients’ customers through the Webpages. 32 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 restrictions (ie proper authentication system) to prevent access from the world wide web over the webpages that were stored on the server. Similar to Re Propnex Realty Pte Ltd, therefore, the present case may be characterised as one which Social Metric had failed in its Protection Obligation to put in the necessary controls to prevent access to personal data held on its Webpages. It was not one where, for example, 13 Social Metric Pte Ltd [2017] SGPDPC 17 the organisation had intentionally disclosed personal data on its website. In those cases, the Commissioner may look into the further issues of whether the organisation was in breach of its Consent and Notification Obligations for disclosing personal data without consent and/or notification. This is illustrated by the case of Re My Digital Lock Pte Ltd [2016] SGPDPC 20. 33 Additionally, not only did Social Metric fail to put in the necessary security measures upon the PDPA coming into full force on 2 July 2014 (ie the Appointed Day), this had carried on well after 2 July 2014. As mentioned earlier at paragraph 6, there were two instances where Social Metric had uploaded personal data of the two individuals on the Webpages in December 2014 and September 2015 respectively. Social Metric’s prolonged failure to put in place the necessary security measures was inexplicable and a flagrant breach of its Protection Obligation under the PDPA. 34 Social Metric alleged that the reason why the customers’ personal data was publicly accessible online was due to oversight or forgetfulness on its part. These are not valid excuses. 35 In consideration of the above, Social Metric, in allowing the Webpages containing personal data to be made publicly available and failing to implement reasonable security arrangements over the Webpages, was in breach of the Protection Obligation. The Commissioner’s Directions 36 Pursuant to section 29 of the PDPA, the Commissioner is empowered to give Social Metric such directions as it deems fit to ensure Social Metric’s compliance with the PDPA. This may include directing Social Metric to pay a 14 Social Metric Pte Ltd [2017] SGPDPC 17 financial penalty of such amount not exceeding S$1 million as the Commissioner thinks fit. 37 In assessing the breach and determining the directions to be imposed to Social Metric in this case, the Commissioner took into account the following factors: (a) the fact that personal data (names and ages) of about 155 children were disclosed; (b) Social Metric did not take prompt remedial actions after being informed of the data breach by the Commissioner; (c) Social Metric had, on more than on occasion, informed the Commissioner that the personal data in question had been deleted when this was not the case; and (d) Social Metric was generally uncooperative throughout the investigation process. Social Metric demonstrated its uncooperative attitude by making unsubstantiated claims such as informing the Commissioner that the data breach was a result of an external hack, and that it had engaged freelance developers located in the Philippines to set up and maintain the Website without providing any evidence of their claims. In addition, Social Metric also caused multiple delays in the investigation process when it repeatedly missed the Commissioner’s deadlines to reply. 38 Having completed its investigation and assessment of this matter, the Commissioner is satisfied that Social Metric was in breach of the Protection 15 Social Metric Pte Ltd [2017] SGPDPC 17 Obligation and the Retention Limitation Obligation under sections 24 and 25 of the PDPA respectively. 39 In consideration of the relevant facts and circumstances of the present case, the Commissioner hereby directs Social Metric to: (a) scan and confirm that its Website no longer stores publicly accessible personal data that is not supposed to be disclosed to the public; and (b) pay a financial penalty of S$18,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. 40 The Commissioner emphasises that he takes a very serious view of any instance of non-compliance with the PDPA, and he urges organisations to take the necessary action to ensure that they comply with their obligations under the PDPA. The Commissioner will not hesitate to take the appropriate enforcement action against the organisation(s) accordingly. YEONG ZEE KIN DEPUTY COMMISSIONER FOR COMMISSIONER FOR PERSONAL DATA PROTECTION 16 ","Financial Penalty, Directions",6e83d465218b035d98cbe2c84b157f8aa0698ca3,"[""pdf-content"",""timestamp"",""decision"",""pdf-url"",""tags"",""nature"",""url"",""title"",""date"",""description""]"