_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,77,77,1,952,"A financial penalty of $4,000 was imposed on Novelship for failing to put in place reasonable security arrangements to protect the personal data collected from its sellers from unauthorised access on its website.","[""Protection"", ""Financial Penalty"", ""Wholesale and Retail Trade"", ""Public access"", ""URL manipulation"", ""No Security Arrangements""]",2020-11-24,https://www.pdpc.gov.sg/-/media/Files/PDPC/PDF-Files/Commissions-Decisions/Decision---Novelship-Pte-Ltd---22072020.pdf,Protection,Breach of the Protection Obligation by Novelship,https://www.pdpc.gov.sg/all-commissions-decisions/2020/11/breach-of-the-protection-obligation-by-novelship,2020-11-24,"PERSONAL DATA PROTECTION COMMISSION Case No. DP-1905-B3820 In the matter of an investigation under section 50(1) of the Personal Data Protection Act 2012 And Novelship Pte. Ltd. SUMMARY OF THE DECISION 1. Novelship Pte. Ltd. (the “Organisation”) operates an e-commerce website for individuals to sell or buy luxury brands of streetwear (the “Website”). To create a buyer or seller account on the Website, individuals would have to provide their personal data to the Organisation. The Organisation does not, in usual course, reveal the personal data it had collected to any buyer or seller transacting on the Website. Instead, the Organisation, together with an external payment processor, facilitates transaction payments on behalf of the parties. 2. On 1 May 2019, the Personal Data Protection Commission (the “Commission”) received information that a registered seller (“User”) was able to gain unauthorised access to the personal data of other sellers by employing software tools and manipulating the public URLs of active listings (“the “Incident”). 3. The User had accessed the personal data of six unique sellers who had active listings at the time of the Incident. The personal data concerned included: (i) first and last names; (ii) email addresses; (iii) shipping addresses; (iv) hashed account passwords; and (v) the name of bank and bank account numbers (“Personal Data Sets”). No buyer data was accessed in the Incident. 4. Investigations revealed that the Organisation had not conducted adequate security testing before the launch of the Website. The testing it had conducted was limited to design and functionality issues, such as verifying the password hashing and password requirement functions. Critically, the Organisation should have—but had not—conducted vulnerability scanning. Vulnerability scanning that is reasonably and competently conducted should include scanning for OWASP Top Ten, i.e. the top 10 security vulnerabilities listed by the Open Web Application Security Project (“OWASP”). The vulnerability of URLs to manipulation is within the OWASP Top 10, and would have been detected if the Organisation had conducted adequate vulnerability testing. 5. The Commission understands that not every organisation is equipped with adequate knowledge of cyber security risks or the ability to conduct security testing. However, the obligation of organisations to protect the personal data they collect and process online cannot depend on their subjective familiarity with the security risks or ability to prevent them. Organisations are expected to engage qualified competent parties, where reasonably needed, to assist them to discharge their obligation to protect personal data. When doing so, organisations can refer on the technical advice and expertise of their service provider, but remain ultimately responsible for articulating the business risks they wish to avoid and business outcomes that they seek to achieve. 6. Similarly, the Commission recognises that organisations may face financial, manpower and technical limitations. These limitations are relevant in establishing the reasonableness of decisions they have taken, but cannot allow an organisation to justify providing a level of protection that is below what is reasonable for the type of personal data it collects and processes. 7. Accordingly, the Deputy Commissioner for Personal Data Protection finds the Organisation in breach of the Protection Obligation under section 24 of the Personal Data Protection Act 2012. 8. Having considered the representations made by the Organisation and the material factors, in particular: (a) the sellers’ personal data would have been at risk of unauthorised access for a period of eight months (from the time the sellers were first allowed to sell on the Website, to the date remedial actions were taken); (b) there was actual unauthorised access of the Personal Data Sets of six individuals by the User; (c) the remedial measures taken by the Organisation upon being made aware of the Incident; which included fixing the vulnerability to ensure that the sellers’ personal data would no longer be accessible to unauthorised persons, redacting all user information relating to bank information, and the Organisation committing to developing a new website; and (d) the adverse impact the COVID-19 pandemic had on the Organisation’s business; the Deputy Commissioner for Personal Data Protection directs that the Organisation pays a financial penalty of S$4,000 for the contravention. The Organisation must make payment of the financial penalty within 30 days from the date of this direction, failing which interest, at the rate specified in the Rules of Court in respect of judgment debts, shall accrue and be payable on the outstanding amount of the financial penalty until it is paid in full. No other directions are required as the Organisation had implemented the necessary remedial measures. ",Financial Penalty,e78daf1170808149ba7ab6af446c1836acb0e555,"[""pdf-content"",""timestamp"",""decision"",""pdf-url"",""tags"",""nature"",""url"",""title"",""date"",""description""]" 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,80,80,1,952,"A financial penalty of $120,000 was imposed on Secur Solutions Group for failing to put in place reasonable security arrangements to protect a database containing the personal data of blood donors from being publicly accessible online.","[""Protection"", ""Financial Penalty"", ""Professional"", ""Scientific and Technical"", ""Database"", ""Gaps"", ""Public access""]",2020-11-24,https://www.pdpc.gov.sg/-/media/Files/PDPC/PDF-Files/Commissions-Decisions/Decision---Secur-Solutions-Group-Pte-Ltd---30032020.pdf,Protection,Breach of the Protection Obligation by Secur Solutions Group,https://www.pdpc.gov.sg/all-commissions-decisions/2020/11/breach-of-the-protection-obligation-by-secur-solutions-group,2020-11-24,"PERSONAL DATA PROTECTION COMMISSION [2020] SGPDPC 8 Case No DP-1903-B3501 In the matter of an investigation under section 50(1) of the Personal Data Protection Act 2012 And Secur Solutions Group Pte Ltd … Organisation DECISION Secur Solutions Group Pte Ltd [2020] SGPDPC 8 Secur Solutions Group Pte Ltd [2020] SGPDPC 8 Tan Kiat How, Commissioner — Case No DP-1903-B3501 30 March 2020 Introduction 1 This case relates to an incident where one of Secur Solutions Group Pte Ltd’s (the “Organisation”) servers, which stored a database (the “Database”) containing personal data of blood donors, was discovered to be accessible from the internet (the “Incident”). 2 The Personal Data Protection Commission (the “Commission”) received a formal request from the Organisation requesting for this matter to be handled under the Commission’s Expedited Breach Decision procedure. In this regard, the Organisation voluntarily provided and unequivocally admitted to the facts as set out in this Decision and that it was in breach of section 24 of the Personal Data Protection Act (the “PDPA”). 2 Secur Solutions Group Pte Ltd [2020] SGPDPC 8 Facts of the Case 3 The Organisation has been engaged by the Health Sciences Authority (“HSA”) since 2013 to develop and maintain various IT systems. One of the projects for which the Organisation was engaged was the development, maintenance and enhancement of its queue management system (“ QMS”) for blood donors (the “QMS Engagement”). Pursuant to the QMS Engagement, HSA provided the Organisation with files containing copies (in part or otherwise) of the Database (“Files”) for the purposes of testing and developing the QMS. HSA would also provide the Organisation with copies or updates of the Database (“Updates”) from time to time during the period of the QMS Engagement (hereinafter, the use of the phrase “Files” will include “Updates”, unless the context specifies otherwise). 4 The Organisation stored the Files in a storage server that was designated for the purposes of testing and development (the “Testing and Development Server”). The Testing and Development Server was accessible through the Internet and unsecured as it was not intended to be used to store personal data or other confidential information. The Server’s system was not actively patched or updated, the router to which the Server was connected did not have a perimeter firewall setup, and there were no firewalls or any other security protocols to restrict access to the Server. 5 At the material time, the Files contained registration-related information (the “Personal Data”) of about 800,000 individual blood donors (the “Affected Individuals”), specifically: (a) Name; (b) NRIC; 3 Secur Solutions Group Pte Ltd 6 [2020] SGPDPC 8 (c) Gender; (d) Handphone number1; (e) Number of blood donations; (f) Dates of the last 3 blood donations; and (g) (In some cases) blood type, height and weight. A cybersecurity expert discovered that he could access the Personal Data in the Database through one of the Organisation’s servers. Based on the forensic investigations conducted by the Organisation, the number of records from the Database that had been exfiltrated amounted to anywhere between 236,023 to 328,546. 7 Upon being notified of the Incident on 13 March 2019, the Organisation took the following remedial actions: (a) Disconnected the Testing and Development Server from the Internet and removed all physical devices connected to the compromised ports to the server; (b) Disabled all remote access to the Organisation’s servers to ensure that all development zones were protected by firewalls; (c) Organised an employee townhall session addressing the Incident; 1This was based on the information provided by the Organisation. 4 Secur Solutions Group Pte Ltd (d) [2020] SGPDPC 8 Appointed external vendors to undertake forensic analysis of the affected servers; (e) Issued press releases to keep the public informed of the Incident and the status of ongoing investigations; (f) Informed its employees not to receive personal data from clients if it was not necessary and to escalate the receipt of personal data (inadvertently or otherwise) to senior management; (g) Conducted further investigation on the security of its Internet lines and Internet-facing services; (h) Began reviewing and improving its internal processes and taking steps to enhance its cybersecurity posture, including appointing a second Data Protection Officer, requiring employees to complete an e-learning program and identifying and remediating any gaps in protection; and (i) Began reviewing its security infrastructure with the assistance of an external vendor, and implementing certain measures, including (i) ensuring all devices used by employees are secured and the anti-virus software installed on these devices are up-to-date, (ii) implementation of a Network Access Control measure, (iii) adoption of a “defence-indepth” approach (including segregation of servers containing sensitive information) and (iv) enhancement of endpoint security measures. Findings and Basis for Determination 5 Secur Solutions Group Pte Ltd 8 [2020] SGPDPC 8 Section 24 of the PDPA requires an organisation to protect personal data in its possession or under its control by making reasonable security arrangements to prevent unauthorised access, collection, use, disclosure, copying, modification, disposal or similar risks. As a preliminary point, the Organisation has accepted that it is a data intermediary of HSA and is required to comply with section 24 of the PDPA with respect to the Personal Data in its possession. Whether the Organisation Complied with Section 24 9 The Organisation has admitted that it has breached section 24 of the PDPA by failing to put in place reasonable security arrangements to protect the Personal Data. 10 The Organisation informed the Commission that it had stored the Files containing the Database in its Testing and Development Server as it did not anticipate that it would be receiving actual copies of production databases from HSA and, as such, did not take any steps to designate any specific security infrastructure set up to receive or store such data on premise. 11 The Organisation admitted that it ought to have been aware that the Files contained personal data even though they had not been specifically informed of this by HSA. In past projects between them, the Organisation had directly retrieved personal data from a production environment on the servers on HSA’s premises for the purposes of testing and development. On this occasion, even though the Files were provided by HSA to the Organisation for the QMS Engagement, from July to August 2018, the Organisation was given access to HSA’s server rooms to retrieve Updates directly from HSA’s servers, an arrangement that made sense if the Files also contained actual personal data (as 6 Secur Solutions Group Pte Ltd [2020] SGPDPC 8 opposed to dummy data). Accordingly, the Organisation ought to have been aware that personal data was contained in the Files, but most definitely in the Updates. 12 In this regard, the Organisation admitted that the Files should not have been stored on the Testing and Development Server, and this was a breach of the Organisation’s own data protection policies and practices, which required that personal data be protected and secured regardless of the purposes for which it was provided. 13 The Organisation has accepted that there were gaps in its data governance and processes with respect to the receipt of test data from its clients. 14 In view of the above, the Commissioner found the Organisation in breach of section 24 of the PDPA. Representations by the Organisation 15 In the course of settling this decision, the Organisation made representations to request that the financial penalty as set out in [19] be paid in the following manner: 16 (a) $60,000 within 30 days from the date of the directions; and (b) $60,000 within 7 months from the date of the directions. The Organisation raised the following factors for the Commissioner’s consideration: (a) The Organisation is a small medium enterprise in a highly competitive IT services industry. It has to contend with rising 7 Secur Solutions Group Pte Ltd [2020] SGPDPC 8 wage costs and increased rentals while battling depressed prices that customers are willing to pay for their services; (b) Arising out of the Incident, the Organisation has: (i) Expended significant resources when it appointed reputable advisors to undertake forensic activities, and sought the advice and assistance of professionals to respond to the police and the Commission’s investigations; (ii) Invested heavily to shore up its data protection and cybersecurity measures, including conducting research and exploring various technologies and methods which may be deployed in protecting data (at rest and in transit) without compromising ease of use of the data; and (c) Payment of the entire financial penalty of $120,000 in one lump sum would negatively affect the Organisation’s cash flow. 17 Having carefully considered the representations, the Commissioner has decided to reject the Organisation’s request at [15]. For the purposes of supporting a request that a financial penalty be paid in instalments, organisations are required to furnish supporting documents on their financial status to the Commission. However, despite the Commission’s repeated requests, the Organisation did not furnish its financial statements and was unable to provide any explanation why it could not to do so. There was therefore no evidence to support the Organisation’s representations on its financial status at [16]. If the Organisation is able to secure documentary evidence of its financial position before the due date for payment as set out at [19], it may submit another request that the financial penalty be paid in instalments. 8 Secur Solutions Group Pte Ltd [2020] SGPDPC 8 The Commissioner’s Directions 18 In determining the directions to be imposed on the Organisation under section 29 of the PDPA, the Commissioner took into account the following factors: Mitigating factors (a) The Organisation was cooperative during the Commission’s investigations; (b) As set out above, the Organisation voluntarily and unequivocally admitted to its contravention of the PDPA; and (c) The Organisation implemented remedial actions swiftly to address the Incident; and Aggravating Factor (d) A subset of the Personal Data was subject to unauthorised access and exfiltration. 19 Having carefully considered all the relevant factors of this case, the Commissioner hereby directs the Organisation to pay a financial penalty of $120,000 within 30 days from the date of the directions, failing which interest at the rate specified in the Rules of Court in respect of judgment debts shall accrue and be payable on the outstanding amount of such financial penalty until the financial penalty is paid in full. 20 The Commissioner took the view that the remedial actions set out at paragraph [7] had sufficiently addressed the risks to the Personal Data arising 9 Secur Solutions Group Pte Ltd [2020] SGPDPC 8 from the Incident. The Commissioner has therefore not set out any further directions for the Organisation. YEONG ZEE KIN DEPUTY COMMISSIONER FOR COMMISSIONER FOR PERSONAL DATA PROTECTION 10 ",Financial Penalty,aa05055fb8dd4b8379487aa1343e9e005c42257d,"[""pdf-content"",""timestamp"",""decision"",""pdf-url"",""tags"",""nature"",""url"",""title"",""date"",""description""]" 2023-10-01T11:02:10+08:00,fbd32491db44d3d0c97aa12a99cefd61ec954264,81,81,1,952,"Directions, including a financial penalty of $7,500 were imposed on Majestic Debt Recovery for failing to obtain consent from its debtors to record the debt collection process. Majestic Debt Recovery also did not obtain consent to upload the recordings onto its Facebook Page. Additionally, Majestic Debt Recovery did not have written policies and practices necessary to ensure its compliance with the PDPA.","[""Protection"", ""Accountability"", ""Directions"", ""Financial Penalty"", ""Others"", ""Consent"", ""No DPO"", ""No Policy""]",2020-11-24,https://www.pdpc.gov.sg/-/media/Files/PDPC/PDF-Files/Commissions-Decisions/Decision---Majestic-Debt-Recovery---02032020.pdf,"Protection, Accountability",Breach of the Consent and Accountability Obligations by Majestic Debt Recovery,https://www.pdpc.gov.sg/all-commissions-decisions/2020/11/breach-of-the-consent-and-accountability-obligations-by-majestic-debt-recovery,2020-11-24,"PERSONAL DATA PROTECTION COMMISSION [2020] SGPDPC 7 Case No DP-1903-B3570 In the matter of an investigation under section 50(1) of the Personal Data Protection Act 2012 And Majestic Debt Recovery Pte Ltd … Organisation DECISION 1 Majestic Debt Recovery Pte Ltd [2020] SGPDPC 7 Yeong Zee Kin, Deputy Commissioner — Case No DP-1903-B3570 2 March 2020 Introduction 1 This case concerns a debt collection company’s posting of a video recording on social media as a tactic to shame a debtor. The recordings in question captured exchanges between the company’s representative and staff of the debtor company. Facts of the Case 2 Majestic Debt Recovery Pte Ltd (the “Organisation”) is a company in the business of collecting debts on the behalf of its clients. On 22 March 2019, the Personal Data Protection Commission (the “Commission”) received a complaint from the managing director (the “Complainant”) of a debtor company (the “Company”) stating that the Organisation had been engaged by the Company’s sub-contractor to recover debts from the Company. The Complainant stated that on or around 21 March 2019, the Organisation’s representatives (the “Representatives”) visited the Company’s premises to collect a debt on behalf of its client (the “Incident”). Not surprisingly, heated words were exchanged with the Company’s personnel when the Representatives attempted to recover the debt. The Representatives recorded video footage of the exchanges with the Company’s personnel, including the Complainant (the “Recording”), on a tablet device. The Complainant and the Company’s personnel could be identified from the images and audio captured by the Recording. According to the Complainant, he “protested against the taking of [the Recording and] posting it [on] social media but [the Representative] said he would do it”. The Representatives nonetheless took the Recording and subsequently posted it on the Organisation’s official public Facebook page (its “Facebook Page”). 2 3 During its investigation, the Commission found other video recordings on the Facebook Page. These videos also captured images and voices of other individuals who appeared to be either individual debtors or representatives of corporate debtors of the Organisation’s clients. 4 By its own admission to the Commission, the Organisation did not have any knowledge of the Personal Data Protection Act 2012 (“PDPA”) prior to this incident and had not developed any data protection policies or practices. The Organisation also admitted that it did not have a data protection officer (“DPO”) prior to this incident. 5 Upon being notified by the Commission, the Organisation took the following remedial actions: (a) Removed the Recording and all other videos from the Facebook Page; (b) Designated an individual tasked with data protection matters (i.e. a DPO); and (c) Assured the Commission that it will ensure that it obtains consent in writing from individuals before recording and uploading their personal data onto its Facebook Page. Findings and Basis for Determination Whether the Organisation had breached section 13 of the PDPA 6 Broadly, section 13 of the PDPA prohibits organisations from collecting, using or disclosing personal data about an individual unless the individual’s consent is obtained (either actual or deemed) or such collection, use or disclosure is required or authorised under the PDPA or any written law. As stated at [2], the Organisation recorded the video using a tablet device. The incident took place at the Company’s premises, after the Representatives were met at the reception and brought into the office proper, which was not open to the public. The Organisation posted the Recording on its Facebook Page despite the Complainant’s protests. This disregard of the individual’s wishes is a breach of section 13 of the PDPA given that the collection, use and disclosure of the Recording was not required or authorised under the PDPA or other written law. 3 7 In relation to the Organisation’s assurance (noted at [5]) that it would in future obtain consent from individuals concerned, it seems unlikely or even unconceivable that an individual who owed a debt would willingly consent to be filmed by the debt collecting agency calling on him, and for such recordings to be posted on social media. If such consent were obtained ex ante by an organisation, for example at the time when the loan was first given, and the purpose for posting the recording on social media is to shame the debtor, there is a real risk that this purpose may not be one which a reasonable person would consider appropriate under section 18 of the PDPA; or that consent thus obtained is vitiated under section 14(3), as having been obtained through unfair, or deceptive or misleading practices. 8 However, this is not to say that the capturing of personal data through video will never be appropriate or in compliance with the PDPA. As an example, a security company may wish to equip its security officers with body worn cameras to ensure that its officers are exercising their duties in a responsible and lawful manner and their interactions with the public adhere to their code of conduct. Any organisation that wishes to implement such a practice has to be accountable and should ensure that it has sound legal basis to do so. Additionally, it will need to put clear guidelines and policies in place for its employees in relation to their conduct and the use of such cameras and the video footage captured. In developing such guidelines and policies, such organisations should ensure that the use of these recording devices are in compliance with the PDPA and have measures and controls in place to ensure that these guidelines and policies are adhered to. Whether the Organisation had breached sections 12 and 11(3) of the PDPA 9 Section 12 of the PDPA requires organisations to, inter alia, develop and implement policies and practices that are necessary for the organisation to meet its obligations under the PDPA, and section 11(3) of the PDPA requires organisations to designate one or more individuals (i.e. the DPO) to be responsible for ensuring the organisations’ compliance with the PDPA. 10 By nature of its business, the Organisation would be in possession and/or control of various personal data, including those of its employees and its clients’ debtors or the debtors’ employees. As stated at [3], the Organisation admitted that it did not have any knowledge of 4 the PDPA prior to being notified by the Commission over this incident, did not have any data protection policies or practices, and had not appointed a DPO. 11 In light of the foregoing, the Organisation was also in breach of sections 11(3) and 12 of the PDPA. Representations by the Organisation 12 In the course of settling this decision, the Organisation made representations regarding the findings as set out at [6]. The Organisation raised the following factors: (a) When the Representatives visited the Company to recover debts on various occasions prior to the Incident they had made video recordings of those visits without any objections from the Company; and (b) According to the Organisation, it had “video proof” of the Complainant consenting to the Organisation posting video recordings of the Representative’s visits to the Company on its Facebook Page. 13 Having carefully considered the representations, I maintain the finding that the Organisation was in breach of Section 13 of the PDPA for the following reasons: (a) The Organisation was unable to provide any evidence to support its assertion that there had been consent by the Company on previous occasions to the Organisation video recording the Representatives’ visits to the Company’s premises. The Organisation was also unable to provide the “video proof” referred to at [12(b)]; (b) Even if consent had been obtained previously, section 16(1) of the PDPA provides that on giving reasonable notice to the organisation, an individual may at any time withdraw any consent given, or deemed to have been given in respect of the collection, use or disclosure by that organisation of personal data about the individual for any purpose. As mentioned at [2], the Complainant had expressly objected to the video recording and the subsequent posting of the video on the Facebook Page. In the circumstances, I find that even if consent was given previously as asserted by the Organisation at [12], it had been withdrawn by virtue of the Complainant’s express 5 objections at the material time. Accordingly, the Organisation did not have consent to post the Recording on its Facebook Page; and (c) Furthermore, even if consent had been obtained to post the video recording on social media to shame the debtor, I have grave doubts if the consent will stand up to scrutiny under section 14(2) of the PDPA, which vitiates consent obtained through unfair, and deceptive or misleading practices. For example, if consent to post video recordings made during debt recovery attempts was made a condition of obtaining the loan, it could possibly go beyond what is reasonable in order to provide the loan: see section 14(2)(a). Consent obtained through such unfair practice is vitiated by section 14(3). Neither would such a purpose be one which a reasonable person — on an objective standard — would likely consider to be appropriate under section 18 of the PDPA. The Deputy Commissioner’s Directions 14 In determining the directions to be imposed on the Organisation under section 29 of the PDPA, I took into account the following mitigating factors: (a) the Organisation was cooperative and forthcoming in the course of investigations; (b) the Organisation took prompt remedial action after being notified by the Commission; and (c) there was no evidence of any further unauthorised use of the personal data captured in the Recording. 15 Having carefully considered all the relevant factors of this case, I hereby direct the Organisation to: (a) pay a financial penalty of $7,500 within 30 days from the date of this direction, 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; 6 (b) develop and implement policies and practices which are necessary for its compliance with the PDPA; and (c) put in place a program of compulsory training for its employees on compliance with the PDPA. YEONG ZEE KIN DEPUTY COMMISSIONER FOR PERSONAL DATA PROTECTION 7 ","Directions, Financial Penalty",735c56aebf1838696565bb02754125b665e3d968,"[""pdf-content"",""timestamp"",""decision"",""pdf-url"",""tags"",""nature"",""url"",""title"",""date"",""description""]"