_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,1,1,1,1016,"A financial penalty of $9,000 was imposed on Century Evergreen for failing to put in place reasonable security arrangements to protect the personal data of jobseekers in its possession or under its control.","[""Protection"", ""Financial Penalty"", ""Employment"", ""URL manipulation""]",2023-09-15,https://www.pdpc.gov.sg/-/media/Files/PDPC/PDF-Files/Commissions-Decisions/GD_Century_Evergreen_260723.pdf,Protection,Breach of the Protection Obligation by Century Evergreen,https://www.pdpc.gov.sg/all-commissions-decisions/2023/09/breach-of-the-protection-obligation-by-century-evergreen,2023-09-15,"PERSONAL DATA PROTECTION COMMISSION [2023] SGPDPCS 5 Case No. DP-2212-C0526 In the matter of an investigation under section 50(1) of the Personal Data Protection Act 2012 And Century Evergreen Private Limited SUMMARY OF THE DECISION 1. On 11 December 2022, the Personal Data Protection Commission (the “Commission”) received a complaint against Century Evergreen Private Limited (the “Organisation”) that images of identification documents (which includes the National Registration Identity Card) submitted by jobseekers to the Organisation were publicly accessible on the Organisation’s website (“Incident”). The Organisation is a manpower contracting services company and required jobseekers to submit their identification documents to verify the identity of and suitability of the jobseeker in question. 2. Following the complaint received, the Commission commenced investigations to determine the Organisation’s compliance with the Personal Data Protection Act 2012 (“PDPA”). The Organisation requested that the investigation be handled under the Commission’s Expedited Decision Procedure (“EDP”). This means that Page 1 of 5 the Organisation voluntarily provided and admitted to the facts set out in this decision. The Organisation also admitted that it failed to implement reasonable security arrangements to protect the personal data in its possession and control, and was in breach of section 24(a) of the PDPA. 3. The Organisation admitted that the Insecure Direct Object References (“IDOR”) vulnerability on its website, which allowed the complainant to manipulate the URL had existed from the time the website was launched on 9 November 2015. As a result of this vulnerability, 96,889 images of identification documents belonging to 23,940 individuals were downloaded from the Organisation’s website from 10 to 12 December 2022. 4. The Organisation admitted that it was in breach of section 24(a) of the PDPA as it failed to include any security requirements to protect personal data in its contract with the vendor who first developed and subsequently maintained the website. In this regard, even though the Organisation had engaged an IT vendor from the time the website was developed and launched, the Organisation remained solely responsible for protecting the personal data in its possession and control at all material times. 5. What is expected from organisations who engage professional services to build their websites and other online portals is explained in the Commission’s Guide on Building Websites for SMEs (revised 10 July 2018) (the “Guide”). The Commission had consistently advised organisations of the need to emphasise the protection of Page 2 of 5 personal data to their IT vendors, by making it part of their contractual terms.1 The contract should clearly state the responsibilities of the IT vendor with respect to the PDPA. In this regard, the Commission noted that there was a glaring omission of clauses to protect personal data in the Organisation’s contract with its IT vendor. 6. The Organisation also admitted that apart from conducting functionality testing when the website was first launched, the Organisation had no arrangements with its IT vendor to conduct any security tests prior to the launch of the website, or thereafter. The Organisation had also failed to impose any security requirements on the IT vendor to protect personal data, via contract. 7. In view of the above, the Deputy Commissioner found that the Organisation had contravened section 24(a) of the PDPA. 8. In deciding the appropriate outcome in this case, the Commission considered that a financial penalty ought to be imposed as the personal data affected included not just the identification numbers, but the images of the identification documents. Furthermore, there was a long period of non-compliance. The vulnerability was not addressed since 2015. 9. In deciding on the appropriate amount of financial penalty, the circumstances set out above and the factors listed at section 48J(6) of the PDPA were considered, specifically the impact of the personal data breach on the individuals affected and the nature of the Organisation’s non-compliance with the PDPA. In the circumstances, this was not an insignificant breach given the number of individuals 1 See Guide on Building Websites for SMEs (revised 10 July 2018) at [4.2.1] and Re EU Holidays Pte Ltd [2019] SGPDPC 38. Page 3 of 5 affected (ie 23,940) and the nature of personal data exfiltrated: 96,889 images of identification documents. 10. The Organisation’s non-compliance with the PDPA was also not simply one of mere negligence but that of gross negligence. There was a long period of noncompliance on the facts of this case. As set out above, the Commission had issued the Guide to assist SMEs, and consistently cautioned the need for organisations to ensure compliance with the PDPA even when they engage an IT vendor in our previous decisions.2 11. In deciding on the appropriate amount of the financial penalty, the following factors were considered – the Organisation’s turnover and profitability, its cooperation throughout the investigation, its voluntary admission of breach of the Protection Obligation under the EDP, and the prompt remedial actions taken after the Organisation became aware of the IDOR vulnerability. This included rectifying the IDOR vulnerability, making server configuration changes to improve security, implementing vulnerability scans, migrating its backup server to an encrypted remote server, deploying additional security software and subscription to security services, and securing a new contract with its vendor to manage the security of its website. In addition to its prompt remedial actions, its poor performance in the most recent financial year was also taken into consideration. Finally, the organisation had admitted to its culpability at an early stage and elected to proceed under the EDP. 2 Re EU Holidays Pte Ltd [2019] SGPDPC 38 and Re Vhive Pte Ltd (Case No. DP-2013-B8138). Page 4 of 5 12. For the reasons above, the Deputy Commissioner for Personal Data Protection hereby finds the Organisation in breach and directs the Organisation to pay a financial penalty of S$9,000 within 30 days from the notice accompanying date of this decision, failing which interest at the rate specified in the Rules of Court in respect of judgement debts shall accrue and be payable on the outstanding amount of such financial penalty until the financial penalty is paid in full. The following section of the Personal Data Protection Act 2012 had been cited in the above summary: Protection of personal data 24. An organisation shall protect personal data in its possession or under its control by making reasonable security arrangements to prevent – (a) unauthorised access, collection, use, disclosure, copying, modification, disposal or similar risks; and (b) the loss of any storage medium or device on which personal data is stored. Page 5 of 5 ",Financial Penalty,3a409dde7f16bfa6ec2d01d5c2d7e80c9ec98146,"[""tags"",""decision"",""pdf-url"",""description"",""date"",""timestamp"",""url"",""title"",""nature"",""pdf-content""]" 2023-10-01T11:02:10+08:00,fbd32491db44d3d0c97aa12a99cefd61ec954264,2,2,1,1016,"A financial penalty of $3,000 was imposed on Autobahn Rent A Car for failing to put in place reasonable security arrangements to protect the personal data in its possession or under its control. Directions were also issued to strengthen access control measures to administrator accounts and to conduct reasonable security review of technical and administrative arrangements for the protection of personal data.","[""Protection"", ""Financial Penalty"", ""Directions"", ""Others""]",2023-09-15,https://www.pdpc.gov.sg/-/media/Files/PDPC/PDF-Files/Commissions-Decisions/GD_Autobahn-Rent-A-Car-Pte-Ltd_090623.pdf,Protection,Breach of the Protection Obligation by Autobahn Rent A Car,https://www.pdpc.gov.sg/all-commissions-decisions/2023/09/breach-of-the-protection-obligation-by-autobahn-rent-a-car,2023-09-15,"PERSONAL DATA PROTECTION COMMISSION [2023] SGPDPCS 4 Case No. DP-2210-C0345 In the matter of an investigation under section 50(1) of the Personal Data Protection Act 2012 And Autobahn Rent A Car Pte. Ltd. SUMMARY OF THE DECISION 1 On 21 October 2022, Autobahn Rent A Car Pte. Ltd. (the “Organisation”) notified the Personal Data Protection Commission (the “Commission”) of a personal data breach (the “Incident”). 2 The Organisation operates a car-sharing service, Shariot, in Singapore. On 24 September 2022, the Organisation received customer feedback that a photograph on its mobile application had been replaced with a pornographic photograph. The Organisation discovered that the pornographic photograph had been uploaded through an unrevoked administrator account belonging to an ex-employee, who had Page 1 of 6 left the Organisation in May 2022. The ex-employee received an email from an unknown sender on 10 September 2022 stating that his personal laptop had been hacked and demanding Bitcoins as ransom payment. The threat actor was able to log into the Shariot’s mobile application administrator portal through the administrator account belonging to the ex-employee, and used the export CSV function to download a copy of the Shariot’s users personal data. 3 Subsequently, on 21 October 2022, a cybersecurity solutions provider alerted the Organisation of a cybercrime forum post offering the sale of a Shariot database containing personal data. The Commission commenced investigations to determine whether the Incident disclosed any breaches of the Personal Data Protection Act 2012 (“PDPA”) by the Organisation. 4 The Organisation requested, and the Commission agreed, for this matter to proceed under the Expedited Decision Breach Procedure. To this end, the Organisation voluntarily and unequivocally admitted to the facts set out in this decision. It admitted to a breach of the Protection Obligation under Section 24 of the PDPA. 5 The Organisation’s internal investigations discovered that compromise of the dormant administrator account credentials enabled the unauthorised access to Shariot backend admin web portal, leading to the exfiltration of 53,000 personal data sets of Shariot users. The personal data that were affected in the Incident included names, Page 2 of 6 email addresses, mobile phone numbers, NRIC numbers and general location data (e.g. Bishan, Toa Payoh or Orchard). 6 Following the Incident, the Organisation took the following remedial action: (a) Immediately conducted an internal audit of its administrator accounts to ensure that any employee access that was not required was revoked; (b) Enhanced its software code and admin panel user interface to mask displayed or exported NRIC numbers to show only the last 4 characters; and (c) Conducted cyber hygiene and awareness training for all staff handling personal data. 7 The Organisation admitted that it had failed to ensure it had reasonable security arrangements in place to prevent the unauthorized access or disclosure of the personal data in its possession or control, as it failed to implement and ensure reasonable access control to its backend admin web portal. First, the Organisation failed to revoke the login credentials of an administrator account belonging to an exemployee once the employment relationship came to an end in May 2022. As a result, the ex-employee’s administrator login credentials remained active, which – when compromised – enabled the malicious actor access into its network. 8 Second, the Organisation also admitted that the Incident would not have happened if it had implemented multi-factor authentication (“MFA”) as an additional Page 3 of 6 access control for its administrator accounts that had access to its sizeable user database. In Re Lovebonito [2022] SGPDPC 3, the Commission had highlighted the need for organisations to strengthen access control, through the use of a one-time password (“OTP”) or 2FA/MFA, to such accounts. Indeed, regardless of whether an account is an administrative account, once an account is granted access rights to a database containing sensitive personal data records or a significant volume of personal data that would adversely impact the affected individuals in the event of a personal data breach, we would encourage organisations to consider implementing enhanced access controls to the account such as through the use of a OTP or 2FA/MFA to better safeguard the personal data. 9 For the above reasons, the Organisation was determined to have breached the Protection Obligation. The Deputy Commissioner’s Decision 10 In determining whether the Organisation should be required to pay a financial penalty under Section 48J of the PDPA or if directions would suffice, I considered that a financial penalty was appropriate as the personal data breach was not insignificant. In deciding the appropriate financial penalty amount, I first considered all the relevant factors listed at Section 48J(6) of the PDPA, in particular, the impact of the personal data breach on the individuals affected and the nature of Organisation’s noncompliance with the PDPA. In this regard, while the NRIC numbers and general Page 4 of 6 location data was affected, this is less serious than if the NRIC images and specific GPS location had been disclosed. 11 In deciding what would be the appropriate financial penalty amount, I also considered the organisation’s turnover to arrive at a figure that would, in my mind, be a proportionate and effective amount, to ensure compliance and deter non-compliance with the PDPA. On the facts of this particular case, the organisation’s turnover has been taken into consideration to arrive at a proportionate and effective financial penalty. I also considered the following mitigating factors, which led to a further reduction in the financial penalty: (a) The Organisation was cooperative during the course of our investigations; (b) The Organisation voluntarily admitted to breach of the Protection Obligation under the Commission’s Expedited Decision Procedure; and (c) The Organisation took prompt remedial actions following discovery of the Incident. 12 For the reasons above, I hereby require the Organisation to pay a financial penalty of $3,000 within 30 days of the date of the relevant notices accompanying this decision, failing which interest at the rate specified in the Rules of Court in respect of judgment debts shall accrue and be payable on the outstanding amount of such financial penalty until the financial penalty is paid in full. Page 5 of 6 13 In addition to the financial penalty imposed, the Organisation is also directed to do the following: (a) Implement processes for systems and applications revocation within a reasonable window of cessation of need for access by an employee; (b) Strengthen access controls measures to administrator accounts with access to databases holding personal data; (c) Conduct reasonable security review of technical and administrative arrangements for the protection of personal data in possession or under control of the Organisation within 60 days of the date of this Direction; (d) Rectify any security gaps identified in the security review directed above; and (e) Inform the Commission within 1 week of the completion on the steps directed above. The following are the provision of the Personal Data Protection Act 2012 cited in the above summary: Protection of personal data 24. An organisation must protect personal data in its possession or under its control by making reasonable security arrangements to prevent – (a) unauthorised access, collection, use, disclosure, copying, modification or disposal or similar risks and; (b) the loss of any storage medium or device on which personal data is stored. Page 6 of 6 ","Financial Penalty, Directions",458ca2b78344d38cc2dec8a4e89a493c8a7475a2,"[""tags"",""decision"",""pdf-url"",""description"",""date"",""timestamp"",""url"",""title"",""nature"",""pdf-content""]" 2023-10-01T11:02:10+08:00,fbd32491db44d3d0c97aa12a99cefd61ec954264,3,3,1,1016,A warning was administered to a registered salesperson of an estate agency for failing to (i) obtain clear and unambiguous consent; or (ii) check the Do Not Call Register before sending specified messages to individuals registered on the Do Not Call Register.,"[""Do Not Call Provision(s)"", ""Warning"", ""Real Estate""]",2023-08-16,https://www.pdpc.gov.sg/-/media/Files/PDPC/PDF-Files/Commissions-Decisions/GD_Leon-Wee_11072023-(004).pdf,Do Not Call Provision(s),Breach of Duty to Check the Do Not Call Register by a Registered Salesperson,https://www.pdpc.gov.sg/all-commissions-decisions/2023/08/breach-of-duty-to-check-the-do-not-call-register-by-a-registered-salesperson,2023-08-16,"PERSONAL DATA PROTECTION COMMISSION [2023] SGPDPC 8 Case No. ENF-DNC-221129-0007 & Others In the matter of an investigation under section 50(1) of the Personal Data Protection Act 2012 And Wee Jing Kai Leon … Person DECISION 1 Wee Jing Kai Leon Wong Huiwen Denise, Deputy Commissioner — Case No. ENF-DNC-221129-0007 & Others 11 July 2023 Introduction 1 The Do Not Call Registry (“DNC Registry”) is a national database kept and maintained by the Personal Data Protection Commission (the “Commission”) pursuant to section 39 of the Personal Data Protection Act 2012 (“PDPA”). Persons may register their Singapore telephone numbers with the DNC Registry so as to not receive unsolicited telemarketing calls and messages. The DNC Registry comprises of 3 separate registers (i) the No Text Message Register, (ii) the No Voice Call Register, and (iii) the No Fax Message Register. 2 Between November 2022 and March 2023, the Commission received ten (10) complaints that one Wee Jing Kai Leon (“Individual”) had sent unsolicited telemarketing messages to telephone numbers registered on the No Text Message Register of the DNC Registry (the “Complaints”). 2 3 The Commission commenced investigations to determine whether there had been any breaches of the “Do Not Call” provisions in Part 9 and 9A of the PDPA (“DNC Provisions”). Facts of the Case 4 The Individual is a real estate salesperson registered with Propnex Realty Pte Ltd since 2006. Over the years, the Individual collated a list of 2,918 Singapore telephone numbers (the “Marketing List”). 5 Of the 2,918 telephone numbers in the Marketing List, 1,224 were registered with the No Text Message Register of the DNC Registry on or around 31 March 2023. 6 The Individual did not send any marketing messages to the telephone numbers on his Marketing List before November 2022 and only admitted to sending a short messaging service message each month from November 2022 to March 2023 (the “SMS Messages”) to the telephone numbers on the Marketing List to offer, advertise and/or promote his services as a real estate salesperson. According to the Individual, by November 2022, the challenging business environment had made it more difficult for him to get leads. He therefore opted to rely on the numbers in the Marketing List to prospect for leads. 7 Given that the Marketing List included 1,224 telephone numbers registered on the DNC Registry, the Individual had sent approximately 6,120 SMS Messages to 3 telephone numbers registered on the DNC Registry from November 2022 to March 2023. 8 The SMS Messages bore the sender ID “Propnex LW”, which is registered under the SMS Sender ID Regime (“SSIR”)1 by DGK Global Pte Ltd (“DGK Global”), a company owned by the Individual. During investigations, the Individual clarified that DGK Global was not involved in his real estate business, and that he used DGK Global to register the sender ID under SSIR because he needed a UEN number to do so. Findings and Basis for Determination The Duty to check DNC Registry under section 43(1) of the PDPA 9 The Commission’s investigation focused on whether the Individual had intentionally or negligently breached section 43(1) of the PDPA by: (a) sending “specified messages” addressed to Singapore telephone numbers, (b) without having valid confirmation that the Singapore telephone numbers were not listed in the DNC Registry at the time the specified messages were sent. 1 The SSIR was set up in March 2022 to enable organisations to protect their customers from receiving fraudulent SMS messages that spoofed the organisations’ SMS Sender IDs. Organisations intending to send SMS messages to Singapore mobile numbers can register any alphanumeric Sender IDs under the SSIR. The Full SSIR Regime came into effect from 31 January 2023, upon which all non-registered Sender IDs will be marked as “LikelySCAM” for a transition period of 6 months. Thereafter, messages with non-registered Sender IDs will be blocked and not delivered to end-users. 4 “Specified message” 10 A message is a “specified message” if one of its purposes is for: 2 (a) (b) Advertising, promoting, or offering to supply or provide: (i) goods or services; (ii) land or an interest in land; (iii) business opportunity or an investment opportunity; Advertising or promoting a supplier or provider (or a prospective supplier or provider) of the items listed in sub-paragraphs (i) to (iii) above. 11 Whether a “specified message” has one of the above purposes is determined with regard to the following:3 (a) the content of the message; (b) the presentational aspects of the message; (c) the content that can be obtained using the numbers, URLs or contact information (if any) mentioned in the message; and (d) if the telephone number from which the message is made is disclosed to the recipient (whether by calling line identity or otherwise), the content (if any) that can be obtained by calling that number. 12 The SMS Messages were “specified messages” within the meaning of the DNC Provisions, as they were sent for the purpose of advertising and/or promoting the Individual’s real estate services. The SMS Messages contained statements such as, 2 3 Tenth Schedule to the PDPA. Section 37(1) of the PDPA. 5 “Engage Professional & Committed Agent to Sell/Rent your Home.”, and “Whatsapp Leon Wee directly at https://chatwith.io/s/enquire to rent/sell your property”. They also included links to the Individual’s website and social media profiles. 13 The Individual admitted that the SMS Messages were addressed to Singapore telephone numbers, as also evidenced by the complaints received by the Commission. Valid confirmation 14 A person can obtain valid confirmation that a Singapore telephone number is not listed in the DNC Registry by doing the following:4 (a) Within 21 days before sending the specified message,5 the person can apply for and receive confirmation from the Commission that the Singapore telephone number is not listed in the relevant register of the DNC Registry;6 or (b) The person can obtain confirmation that the Singapore telephone number is not listed in the relevant register of the DNC Registry from a “checker”,7 but must not have reason to believe that, or be reckless as to whether the checker’s information was obtained more than 21 days ago, or is false or inaccurate. 4 Section 43(2) of the PDPA. Section 15 of the Personal Data Protection (Do Not Call Registry) Regulations 2013 (the “DNC Regulations”). 6 Under section 40(2) of the PDPA 7 A “checker” refers to a person that, for a reward, provides to another person (P) information on whether a Singapore telephone number is listed in the relevant register for the purpose of P’s compliance with Section 43(1) of the PDPA. A “checker” is a person other than the Commission, an employee of P, and an employee or agent of a checker. 5 6 15 Investigations revealed that the Individual did not obtain valid confirmation that the telephone numbers on his Marketing List were not listed in the DNC Registry. Whether the Individual received clear and unambiguous consent 16 Even if a specified message is sent to a Singapore telephone number without valid confirmation that the number is not listed in the DNC Registry, a person does not contravene section 43(1) of the PDPA if: (a) the subscriber or user of the Singapore telephone number gave clear and unambiguous consent to the sending of the specified message; and (b) the consent is evidenced in writing or other form so as to be accessible for subsequent reference8. This means that the consent must be captured in a manner or form which can be retrieved and reproduced at a later time in order to confirm that such consent was obtained. Possible forms include an audio or video recording of the consent given9. 17 In the course of investigations, the Individual represented to the Commission that he was under the impression that since he had obtained the telephone numbers prior to the enactment of the PDPA, he could use them for marketing purposes. 18 The Commission recognises that a subscriber of a Singapore telephone number is deemed to have given his consent to a person to send a specified message to that Singapore telephone number if the subscriber consents to the sending of the 8 9 Section 43(4) of the PDPA. [8.3] of the Advisory Guidelines on the DNC Provisions (revised 1 February 2021) 7 specified message before 2 January 2014 (i.e. before the DNC Provisions came into effect), and that consent has not been withdrawn.10 Even if the subscriber subsequently adds his telephone number to the DNC Registry, this would not amount to withdrawal of consent.11 19 However, this does not relieve the Individual of his obligations under section 43(4) to obtain the consent of the subscribers or users of the Singapore telephone number to which a specified message is sent to him. In other words, if the Individual intended to rely on section 43(4) of the PDPA, he should have obtained clear and unambiguous consent to the sending of the SMS Messages to the telephone numbers in his Marketing List from the subscribers of the Singapore telephone numbers contained therein evidenced in written or other forms. The Commission sets out, at [8.5] of the Advisory Guidelines on the DNC Provisions (revised 1 February 2021), various methods through which such consent can be obtained from the subscribers or users: “For example, persons may seek to obtain consent by asking individuals to: a) respond to a pop-up on a webpage; b) respond to pop-ups or other form of notifications within mobile applications; c) fill out and submit a web form; d) fill out and submit a physical form; e) indicate their choice by signing or ticking against a check box printed on a letter or service agreement; or 10 11 Section 47(4) of the PDPA. Section 47(5) of the PDPA. 8 f) call or send an SMS to the person.” 20 The Commission found no evidence of the Individual obtaining such clear and unambiguous consent from any of the subscribers of the Singapore telephone numbers on the Marketing List, in written or other forms before or after 2 January 2014. 21 Accordingly, the Individual failed to obtain valid confirmation that the telephone numbers in the Marketing List are not listed in the DNC Registry before sending the SMS Messages, and has negligently contravened section 43(1) of the PDPA. Whether the Individual is an employee acting in the course of employment 22 For completeness, the Commission assessed whether the defence under section 48 of the PDPA was available to the Individual, and concluded that it was not. Section 48(2) provides that section 43(1) does not apply to an employee who sends a specified message to a Singapore telephone number if he can prove that he did so in good faith in the course of his employment or in accordance with instructions given to him by or on behalf of his employer in the course of his employment. The Commission considered the following: (a) In accordance with industry practices, real estate salespersons such as the Individual are not in an “employer-employee relationship” with their agencies. (b) The Individual confirmed that he is not an employee of Propnex Realty Pte Ltd (“Propnex”) despite being registered with them. He does not 9 receive salary from Propnex, nor does Propnex provide the Individual with medical benefits, CPF contributions, or annual leave benefits. The Individual is self-employed and does not report to Propnex on the conduct of his business. (c) The contents of the SMS Messages related to the services of the Individual specifically, and not Propnex. The Deputy Commissioner’s Decision 23 In determining whether any financial penalties or directions should be imposed on the Individual, the Commission took the following into consideration: (a) The Individual was cooperative with the Commission’s investigations; (b) The Individual had otherwise made efforts to ensure his compliance with other DNC Provisions, in particular the requirement under section 44 of the PDPA to include clear and accurate information identifying the sender of the SMS Messages and how he can be readily contacted. He had also provided recipients the option to unsubscribe from the SMS Messages, and would remove a recipient’s telephone number from the Marketing List if so requested; and (c) The Individual’s efforts to register the sender ID “Propnex LW” showed a willingness to comply with regulatory regimes, in particular the SSIR. 24 Having considered all the factors listed above, the Individual is hereby administered a warning in respect of his breach of section 43(1) of the PDPA. No other 10 directions are necessary in view of the Individual’s voluntary cessation of sending specified messages to numbers on the Marketing List. 25 The Commission observes that this case occurred alongside media reports of an increase in property scams. The Commission has also investigated complaints involving property agents who had concealed their identities while sending marketing messages in contravention of the DNC Provisions. For the avoidance of doubt, while there was no evidence that the Individual was involved in any scams or had attempted to conceal his identity in his marketing messages, the Commission will continue to monitor this trend involving property agents and calibrate its decisions in future cases accordingly to ensure compliance with the DNC Provisions of the PDPA. WONG HUIWEN DENISE DEPUTY COMMISSIONER FOR PERSONAL DATA PROTECTION 11 ",Warning,f18593fdbb15638a11bc2083adacad1a58daf1b2,"[""tags"",""decision"",""pdf-url"",""description"",""date"",""timestamp"",""url"",""title"",""nature"",""pdf-content""]" 2023-10-01T11:02:10+08:00,fbd32491db44d3d0c97aa12a99cefd61ec954264,4,4,1,1016,"A financial penalty of $74,400 was imposed on Ecommerce Enablers for failing to put in place reasonable security arrangements to protect users' personal data in its possession or under its control.","[""Protection"", ""Financial Penalty"", ""Wholesale and Retail Trade""]",2023-08-16,https://www.pdpc.gov.sg/-/media/Files/PDPC/PDF-Files/Commissions-Decisions/Decision---Ecommerce-Enablers.pdf,Protection,Breach of the Protection Obligation by Ecommerce Enablers,https://www.pdpc.gov.sg/all-commissions-decisions/2023/08/breach-of-the-protection-obligation-by-ecommerce-enablers,2023-08-16,"PERSONAL DATA PROTECTION COMMISSION [2023] SGPDPC 6 Case No. DP-2009-B7056 In the matter of an investigation under section 50(1) of the Personal Data Protection Act 2012 And E-Commerce Enablers Pte. Ltd. … Organisation DECISION Page 1 of 11 E-Commerce Enablers Pte. Ltd. Lew Chuen Hong, Commissioner — Case No. DP-2009-B7056 16 May 2023 Introduction 1 On 25 September 2020, E-Commerce Enablers Pte. Ltd. (“Organisation”) notified the Personal Data Protection Commission (“PDPC”) and its customers of an incident involving unauthorised access to its customer data servers (the “Incident”). PDPC subsequently received 2 complaints from the Organisation’s customers in relation to the Incident. On 12 November 2020, the Organisation's customer database was offered for sale on an online forum indicating that personal data was exfiltrated during the Incident. 2 PDPC commenced investigations to determine the Organisation’s compliance with the Personal Data Protection Act 2012 (“PDPA”) in relation to the Incident. Facts of the Case 3 The Organisation runs an online platform offering cashback for purchases made through affiliated merchant programs. The platform also provides coupons, voucher codes, and comparison features with discounts for users. 4 At the time of the Incident, the Organisation hosted its customer database on virtual servers in an Amazon Web Services (“AWS”) cloud environment (“Customer Page 2 of 11 Storage Servers”). The Organisation employed a 12-man Site Reliability Engineering (“SRE”) team whose responsibilities included maintaining the Organisation’s infrastructure, providing, and managing the Organisation’s cloud environment on AWS, and ensuring security of the AWS keys. The SRE team made use of an AWS access key with full administrative privileges (the “AWS Key”) for the purposes of its work, including infrastructure deployment. Only SRE team members had access to, and were authorised to use, the AWS Key. On 4 June 2019, the AWS Key was inadvertently committed to software code in a private repository in GitHub, by a senior member of the SRE team. This was discovered by another SRE team member on 6 June 2019, and the AWS Key was removed from GitHub on the same day. However, it remained viewable in GitHub’s ‘commit history’, which records all changes and previous versions of code uploaded on GitHub. 5 On 21 June 2019, the AWS Key was to be deleted and replaced by a new key as part of an out-of-cycle key rotation. The member of the SRE team in charge of the key rotation informed the SRE team (via email) that he had created a new key to replace the AWS Key, and that he would be deleting the AWS Key. However, after creating the replacement key, he failed to fully disable and remove the AWS Key. 6 As a result, the AWS Key continued to be usable to access the Organisation’s AWS environment (and consequently the Customer Storage Servers) until shortly after the time of the Incident, about 15 months later. Page 3 of 11 The Incident 7 On 9 September 2020, a malicious threat actor accessed the Organisation’s AWS environment utilizing the AWS Key. The AWS Key was likely found by the threat actor in the commit history of the GitHub private repository. 8 Having gained privileged access to the AWS environment, the threat actor (i) conducted reconnaissance to identify the Organisation’s data repositories, (ii) modified security settings including to allow remote internet access to the Organisation’s database instances (i.e. its virtual servers hosting data), and (iii) generated a fresh database instance to stage its data exfiltration. 9 The threat actor then proceeded to exfiltrate data from the Customer Storage Servers. The data items, and the corresponding number of individuals affected, are set out below: Types of personal data Email Address Number of affected users 1,457,637 Name 840,210 Mobile number 447,076 Address 138,327 Gender 23,278 NRIC numbers 9,961 Date of birth 202,634 Bank Account number 299,381 Partial credit card information, including: 378,531 Page 4 of 11 (i) partial credit card number (first 6 digits and last 4 digits) (ii) issuing bank (iii) country (iv) expiry month and year (v) Visa or Mastercard 10 On 17 September 2020, the Organisation discovered during a routine security review that there had been unauthorised access to its AWS environment. Further investigations revealed that there had been unauthorised third-party access to the Organisation’s AWS environment. 11 The Organisation subsequently engaged a private forensic expert, (“PFE”) to investigate further. The PFE confirmed that the unauthorised access had been carried out using the AWS Key. The Organisation conjectured that it was likely that the threat actor had obtained the AWS Key from GitHub’s commit history, where the AWS Key was still visible despite the removal of the wrongly committed code from the private repository in GitHub. Remedial actions 12 Following the Incident, the Organisation implemented the following remedial measures: Immediate remedial steps to contain the Incident (a) Performed a full deletion of the AWS Key and rotated the other AWS keys; Page 5 of 11 (b) Reversed all changes made by the threat actor and triggered a forced logout and password reset of all customers’ accounts; To prevent recurrence or similar incidents (c) Increased monitoring of logs to ensure heightened detection of any unauthorised access; (d) Separated development and production accounts, resulting in a smaller subset of engineers having access to the production environment; (e) Secured access to systems and data with several measures, including VPN and IP address whitelisting and database encryption; and (f) Created a platform for employee security suggestions / breach reporting. Subsequent sale of personal data on Raidforums 13 On 12 November 2020, the Organisation’s database was offered for sale on Raidforums, an online cybersecurity forum commonly used for trading and selling of stolen databases. Raidforums’ domain name and content was independently seized by authorities from the United States in April 2022. Findings and Basis for Determination 14 Based on the circumstances of the Incident, the Commission’s investigation centred on whether the Organisation had breached its obligations under section 24 of the PDPA to protect personal data in its possession or under its control, by making reasonable security arrangements to prevent unauthorised access, collection, use, Page 6 of 11 disclosure, copying, modification, disposal, or similar risks (the “Protection Obligation”). The Organisation was determined to have breached the Protection Obligation in two respects. Lack of sufficiently robust processes for AWS key management 15 First, the Organisation failed to ensure that processes to manage the AWS keys that granted access to the Customer Storage Servers were sufficiently robust. 16 While the Organisation admitted that it could have done more to ensure that its employees were performing their AWS key rotation duties properly, the Organisation claimed that the compromise of the AWS Key arose from human error, and not because of any systemic issue with the Organisation’s security practices. According to the Organisation, there was no reason to doubt the capabilities of the SRE team member in question, because (i) he was a senior member of the SRE team, (ii) his responsibilities included key security and rotation, and (iii) he had dutifully rotated / deleted all other keys assigned to him in the out-of-cycle key rotation. The SRE team member’s inadvertent commit, and an incomplete rotation/deletion were in direct contravention of the Organisation’s security practices. The Organisation accordingly sought to frame the Incident as a one-off case of human error. 17 This position is not accepted. As explained in Re DataPost Pte Ltd, Organisations cannot place sole reliance on their employees to perform their duties properly as a security arrangement to protect personal data. There must be some Page 7 of 11 processes to ensure that the step required from the employee is taken, such as independent verification by another checker1. 18 For example, a precaution the Organisation could have taken to ensure that the out-of-cycle key rotation was complete would have been to have a supervisor or another SRE team member test either all or a reasonable sample of the old keys (depending on the number of keys being rotated) to verify that they had been disabled. There was no such verification or testing practice put in place by the Organisation; the Organisation relied wholly on the SRE team member’s seniority and experience. 19 When a high-risk task (e.g. rotation of an AWS key that gives access to the whole of the AWS environment) is concerned, it is all the more important that there must be additional verifications and checks. Failure to conduct periodic security review 20 Second, specific security review by the Organisation on AWS keys could have covered and detected whether the AWS Key remained active or had been used after the out-of-cycle key rotation, and during the 15 months preceding the Incident. The Organisation failed to conduct regular security review on whether the AWS keys had been properly rotated/deleted. In the course of investigations, the Organisation acknowledged that it could have done more to ensure that the SRE team was performing their AWS key rotation duties properly. Following the Incident, the 1 Re DataPost Pte Ltd [2017] SGPDPC 10, at [13] – [16] Page 8 of 11 Organisation implemented a more secure process for temporary, time-limited keys to be issued to SRE team members whenever access to the AWS environment was required. The Organisation also developed a specific IT security policy concerning the secure sharing of keys internally. Observation on the incident management processes 21 Following discovery of the inadvertent committal of the AWS Key to GitHub, the Organisation took 15 days to conduct a key rotation. Regardless of whether this had been an out-of-cycle rotation, the Organisation should review its incident management processes to determine whether it was reasonable to have taken 15 days to remediate compromise of a full administrative privilege AWS access key. The Commissioner’s Decision 22 In determining whether to impose a financial penalty on the Organisation pursuant to section 48J(1) of the PDPA, and the amount of any such financial penalty, the matters set out at section 48J(1) and the factors listed at section 48J(6) of the PDPA were taken into account, including the following aggravating and mitigating factors: Aggravating Factors (a) The Organisation lacked sufficiently robust processes to monitor its incident management response to ensure reasonable remediation speed, which led to 15 days passing before the Organisation responded to the exposure of the AWS Key; Page 9 of 11 (b) The AWS Key was exposed for a long period of 15 months; Mitigating Factors (a) The Organisation took prompt remedial actions, including notifying the affected individuals; (b) The Organisation was cooperative during investigations; and (c) The Organisation voluntarily acknowledged that its failure to ensure proper rotation and deletion of the AWS Key constituted a breach of the Protection Obligation. 23 The Organisation was notified of the preliminary decision by way of the Commission’s letter dated 15 February 2023 and was invited to make representations on the same. The Organisation made representations on 22 March 2023, albeit not on its liability for breaches of the Protection Obligation or on the proposed financial penalty. Where accepted by the Commission, these representations have been incorporated into this decision. 24 Having considered all the relevant circumstances of this case, the Commissioner hereby requires the Organisation to pay a financial penalty of $74,400 within 30 days from the date of the relevant notice accompanying this decision, failing which interest at the rate specified in the Rules of Court in respect of judgment debts shall accrue and be payable on the outstanding amount of such financial penalty until the financial penalty is paid in full. Page 10 of 11 25 No further directions are necessary on account of the remedial measures already taken by the Organisation. Page 11 of 11 ",Financial Penalty,76e1a0c6ce1eec405d0c28dbde5757aff32b2192,"[""tags"",""decision"",""pdf-url"",""description"",""date"",""timestamp"",""url"",""title"",""nature"",""pdf-content""]" 2023-10-01T11:02:10+08:00,fbd32491db44d3d0c97aa12a99cefd61ec954264,5,5,1,1016,"A financial penalty of $58,000 and $10,000 was imposed on Fullerton Healthcare and Agape CP Holdings respectively for failing to put in place reasonable security arrangements to protect personal data belonging to Fullerton Healthcare’s corporate clients and direct patients. Directions were also issued to both organisations to review and enhance processes relating to data handling processes, security audits and access controls to bolster their data protection arrangements.","[""Protection"", ""Financial Penalty"", ""Directions"", ""Healthcare"", ""Public access""]",2023-06-22,https://www.pdpc.gov.sg/-/media/Files/PDPC/PDF-Files/Commissions-Decisions/GD_Fullerton-Healthcare-Group-and-Agape-CP-Holdings_230323.pdf,Protection,Breach of the Protection Obligation by Fullerton Healthcare and Agape CP Holdings,https://www.pdpc.gov.sg/all-commissions-decisions/2023/06/breach-of-the-protection-obligation-by-fullerton-healthcare-and-agape-cp-holdings,2023-06-22,"PERSONAL DATA PROTECTION COMMISSION [2023] SGPDPC 5 Case Nos. DP-2110-B9054 / DP-2110-B9060 In the matter of an investigation under section 50(1) of the Personal Data Protection Act 2012 And (1) Fullerton Healthcare Group Pte Limited (UEN No. 201020358N) (2) Agape CP Holdings Pte. Ltd. (UEN No. 201435153E) … Organisations DECISION 1 (1) Fullerton Healthcare Group Pte Limited (2) Agape CP Holdings Pte. Ltd. Lew Chuen Hong, Commissioner — Case Nos. DP-2110-B9054 / DP-2110-B9060 23 March 2023 Introduction 1 On 19 October 2021 and 21 October 2021, Fullerton Healthcare Group Pte Limited (“FHG”) and Agape CP Holdings Pte. Ltd. (“Agape”) respectively notified the Personal Data Protection Commission (the “Commission”) that the personal data of FHG’s customers had been accessed, exfiltrated, and offered for sale on the dark web (the “Incident”). The Commission commenced investigations to determine whether the Incident disclosed any breaches of the Personal Data Protection Act 2012 (“PDPA”) by FHG and Agape. 2 On 11 January 2022 and 12 January 2022 respectively, FHG and Agape requested for the investigations to be handled under the Commission’s Expedited Decision Procedure. In this regard, FHG and Agape voluntarily provided and admitted to the facts set out below and admitted that they had failed to implement reasonable 2 security arrangements to protect the personal data accessed and exfiltrated in the Incident in breach of section 24 of the PDPA (the “Protection Obligation”). Facts of the Case 3 FHG is an enterprise healthcare service provider which provides healthcare services to individuals and employees of its corporate clients. In 2018, FHG engaged Agape, a business process outsourcing provider and social enterprise, to provide call centre and appointment booking services for its customers (the “Services”). As part of its social enterprise initiatives, Agape engaged inmates from Changi Women’s Prison (the “Agents”) to assist in provision of the Services for FHG’s customers. 4 In order to carry out the Services, FHG provided Agape with access to the personal data of its customers via Microsoft SharePoint, a cloud-based document management system. A single Agape personal computer (the “Computer”) was authorised to access FHG’s SharePoint platform via an FHG-assigned SharePoint account. 5 In order to facilitate Agents’ access to FHG’s customer data from within Changi Women’s Prison, Agape downloaded FHG’s customer data onto the Computer, and re-uploaded the customer data onto an internet-facing file server (“the Online Drive”). The Online Drive was then white-listed for access by the Agents from within Changi Women’s Prison. 3 The Incident 6 On 15 October 2021, FHG became aware that its customer data was being offered for sale on a dark web forum. FHG engaged cybersecurity consultants to investigate. On 18 October 2021, FHG’s cybersecurity consultants made contact with the purported seller who claimed that he had exfiltrated FHG’s customer data from Agape’s Online Drive. By 22 October 2021, the post on the dark web forum advertising the sale had been removed. 7 FHG’s cybersecurity consultants confirmed that the Incident solely involved and affected Agape’s Online Drive. FHG’s own systems and servers were not affected in the Incident. 8 The personal data of 156,900 FHG customers (133,866 direct patients and 23,034 employees of FHG’s corporate clients) was accessed without authorisation in the Incident, although the exact volume of exfiltrated personal data was unknown. The affected personal data comprised the following datasets: Direct patients (a) Name; (b) NRIC number / FIN; (c) Date of birth; (d) Gender; (e) Email address; 4 (f) Telephone number; (g) Financial information (Bank account numbers and bank codes); (h) Health information (International Classification of Diseases codes that pertain to an individual’s diagnosis information, and codes for surgical procedures done in hospitals); Employees of FHG’s corporate clients (i) Name; (j) NRIC number / FIN / Passport number; (k) Date of birth; (l) Email address; (m) Financial information; and (n) Health, and other information (Information relating to the utilisation of health benefits by individual members, which include details of clinic names and claim amount (collectively, the “Customer Data”). Remedial actions 9 As part of remedial measures following the Incident, FHG informed affected clients and individuals promptly via SMS, email, and an FAQ page on its website, advising on appropriate steps which could be taken to guard against potential risks. FHG also engaged Credit Bureau (Singapore) Pte Ltd to provide free credit monitoring services to affected individuals for 6 months. 5 10 Agape suspended use of the Online Drive with effect from 19 October 2021, and, with the assistance of a forensic team, conducted internal checks on the Computer and Online Drive for other indicators of compromise. 11 FHG in coordination with Agape also: (a) restricted Agape’s access to its SharePoint to “view-only”; (b) deleted SharePoint files and folders that Agape did not need as part of data minimisation efforts; (c) ceased synchronisation of data between SharePoint and the Computer; (d) changed all passwords for Agape’s access to FHG’s SharePoint; and (e) deleted the Customer Data from the Online Drive upon completion of Agape’s investigations into the Incident. Findings and Basis for Determination Whether Agape had contravened the Protection Obligation 12 As a data intermediary of FHG, Agape is subject to the Protection Obligation pursuant to section 4(2) of the PDPA. For the reasons set out below, Agape was determined to have breached the Protection Obligation in relation to the Customer Data affected in the Incident. 6 Failure to conduct reasonable periodic security reviews 13 In previous enforcement decisions, the Commission has emphasised the need for organisations to conduct periodic security reviews of their IT systems. Such reviews enable organisations to detect vulnerabilities, assess security implications and risks, and ensure that reasonable security arrangements are implemented to eliminate or mitigate such risks. Periodic security reviews should be scoped based on the organisation’s assessment of its data protection needs, for example, taking into account the type of personal data to be protected.1 14 In Quoine Pte Ltd [2022] SGPDPC 2 (“Quoine”), while the organisation had conducted periodic security reviews, these security reviews were improperly scoped and failed to include a particular account. The organisation explained that its current staff were not aware of the reasons for the affected account’s set-up and security arrangements, as the account had been created “at some time in the past (so legacy)”. This explanation did not excuse the organisation’s breach of the Protection Obligation. The Commission found that it was incumbent on the organisation to have implemented the necessary systems and processes to ensure that critical information about its systems, including legacy systems, survived the turnover of its staff (Quoine at [23]). 15 Similarly, while Agape had carried out periodic security reviews, these reviews failed to cover the Internet-facing Online Drive. Agape admitted that this omission was 1 Everlast Projects Pte Ltd and others [2020] SGPDPC 20 (at [21]). 7 because the use of the Online Drive had been a legacy feature unique to Agape’s engagement by FHG, which was not implemented for any of Agape’s other clients. As a result of this omission, Agape failed to review and assess the Online Drive’s security implications and risks. 16 When the Online Drive was installed in December 2017, it was protected by a password which met Agape’s password complexity policy (i.e. 8 to 10 characters with a mix of upper and lower-case characters, numbers and symbols). However, at the time of the Incident, the password for Agape’s Online Drive had been inadvertently disabled for an estimated 20 months (since December 2019), the cause of which could not be established. Agape admitted that this caused the Online Drive to become an open directory listing on the Internet with no password protection, and highly vulnerable to unauthorised access, modification and similar risks over an excessive period of time. 17 If Agape’s periodic reviews had been properly scoped to cover all of the IT components under its Services rendered to FHG (including the Online Drive), this lapse could have been detected and rectified timeously. Inadequate password policy and management 18 In the course of investigations, Agape also admitted that prior to the password being disabled in December 2019, it had been shared by Agents to access the Online 8 Drive. In Terra Systems Pte. Ltd. [2021] SGPDPC 72, the Commission highlighted the data protection risks associated with multiple users sharing a common password, including greater risks of unauthorised access by ex-staff and inadvertent disclosure to threat actors through social engineering, among others. 19 The use of a common password among all Agents was exacerbated by the fact that there was no expiry date set for the password. The failure to implement and enforce reasonable password management policies increased the vulnerability of the Customer Data on the Online Drive to unauthorised access and other similar risks, even before the password had been disabled. 20 For the above reasons, Agape was determined to have breached the Protection Obligation. Whether FHG had contravened Section 24 of the PDPA Failure to exercise reasonable oversight of vendor 21 Under Section 4(3) of the PDPA, an organisation that engages a data intermediary to process personal data on its behalf, bears the same obligations under the PDPA as if the personal data was processed by the organisation itself. This is so, even where the organisation engages the data intermediary to implement the 2 This decision was subsequently subjected to reconsideration by the Commission. In Terra Systems Pte Ltd [2022] SGPCPCR 1, the Commissioner affirmed the finding of the organisation’s breach of Section 24 of the PDPA and the financial penalty imposed. 9 necessary data protection measures in relation to the personal data (Social Metric Pte Ltd [2017] SGPDPC 17 at [15]). 22 The Commission has reiterated in past decisions, such as SCAL Academy Pte. Ltd. [2020] SGPDPC 2, that the Protection Obligation requires organisations to exercise reasonable oversight of their vendors. 23 Specifically in the context of an organisation’s relationship with its data intermediary, the organisation (i.e. the data controller) 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 or control over the personal data. This means that a data controller may be found in breach of the Protection Obligation, even though its data intermediary may not be found in breach, and vice versa (Social Metric Pte Ltd [2017] SGPDPC 17 at [16]). 24 In this case, FHG engaged Agape as its data intermediary to carry out the Services using the personal data provided by FHG. Under the Protection Obligation, FHG was required to exercise reasonable oversight of Agape’s data processing activities. 25 In SCAL Academy Pte. Ltd. [2020] SGPDPC 2 (at [8]), even though the organisation in question had instructed its vendor to prevent certain documents from 10 being ‘leaked’ online, it did not check what security arrangements the vendor had implemented to ensure this. This hindered the organisation and vendor from being able to identify any data protection risks and agree on the measures to be implemented to protect against unauthorised disclosure of the personal data in the documents. 26 In this case, due consideration is given to the fact that FHG had conducted a high-level IT due diligence review of Agape prior to its decision to onboard Agape as a vendor, and that FHG’s written agreement with Agape required the latter to comply with the PDPA including, among others, obligations to take all appropriate and reasonable administrative, physical and technical safeguards, and security arrangements. Nevertheless, FHG’s failed to exercise reasonable oversight through regular monitoring of Agape’s personal data handling processes throughout the engagement, including how Agape stored and granted Agents’ access to the Customer Data. 27 In this regard, there was a point of contention between the parties over whether FHG was aware of and permitted the uploading of the Customer Data from Agape’s Computer to the Internet-facing Online Drive. 28 According to FHG, its understanding with Agape was that the local copy of the Customer Data on the Computer was only to be used for emergency or exceptional situations such as when Agape was unable to connect to FHG’s SharePoint during any system downtime or disruptive event. No other copies of the Customer Data were 11 to be made by Agape, whether from the SharePoint or the local copy on the Computer. FHG stated that it did not provide Agape with permission to upload the Customer Data from Agape’s Computer to the Online Drive. 29 In contrast, Agape asserted that FHG was aware that the Agents were inmates operating from inside Changi Women’s Prison, and that there were IT restrictions preventing them from accessing the Customer Data directly from FHG’s Sharepoint. As such, Agape had downloaded and uploaded the Customer Data onto its Online Drive for the Agents to access and use. Agape asserted that FHG was aware of Agape’s process of sharing Customer Data with the Agents as FHG’s representatives had been present during “dry runs”. 30 While there was insufficient contemporaneous evidence to support either party’s version of events, the fact remains that FHG was aware that Agape was engaging inmates from inside Changi Women’s Prison to carry out the Services, and the Commission’s findings regarding FHG’s breach of the Protection Obligation are not dependent on whether FHG permitted Agape to upload the Customer Data to the Online Drive or not. 31 Given that FHG was aware that access to the Customer Data would have to be granted to a third party that was offsite for the provision of the Services, FHG should have made reasonable enquiries to ascertain how the Customer Data was to be stored and transmitted, and how access to the Customer Data would be controlled. Had FHG 12 made these enquiries and discovered the true state of affairs, they would have no doubt required Agape to implement stricter controls to regulate Agents’ access and use of the Customer Data. By failing to make such enquiries, FHG failed to appreciate the reality of how Agape was storing, transmitting, and retaining the Customer Data, and failed to exercise reasonable oversight over Agape’s data processing activities. Unnecessary disclosure of sensitive personal data 32 Separately, FHG inadvertently disclosed personal data only intended for its employees’ internal use, onto the SharePoint system shared with Agape. This included sensitive financial information such as bank account numbers and bank codes, and health information such as ICD codes and codes for surgical procedures done in hospitals. These datasets were not required by Agape for the performance of the Services, and this inadvertent disclosure ultimately led to a greater loss of personal data during the Incident. 33 When an organisation discloses more personal data than is needed for its purposes, this creates unnecessary data security risks, particularly where such data is more sensitive in nature3. 3 Habitat for Humanity Singapore Ltd [2018] SGPDPC 9 (at [19]-[20]) 13 34 In the Commission’s Guide to Data Protection Practices for ICT Systems4 (at page 11), data minimisation has been encouraged as a good way for organisations to examine what personal data is really needed. It should be a basic data protection practice for organisations to collect, use, or disclose only the least sensitive types of personal data if different types of personal data can be used to achieve the same purpose. 35 FHG should have implemented robust measures to ensure that only personal data necessary for performance of the Services was shared with Agape, and in particular, that sensitive personal data was not inadvertently disclosed. 36 In view of the above, FHG was determined to have breached the Protection Obligation in respect of the Customer Data. Voluntary measures implemented by FHG and Agape 37 Following the Incident, FHG and Agape have voluntarily taken or will be taking the following steps to prevent a recurrence of the Incident or similar events: FHG (a) Agents will now access FHG’s customer data directly from FHG’s SharePoint via individual user accounts with multi-factor authentication; 4 Published on 14 September 2021. The Guide compiles data protection practices from past Advisory Guidelines, Guides and data breach cases that should be adopted by organisations in their ICT policies, systems and processes. 14 (b) FHG’s SharePoint has been reconfigured to grant “view-only” access to only the specific files required by vendors for the services to be provided, with clear segregation between the vendor’s SharePoint files and FHG’s internal SharePoint files; (c) FHG will formally communicate its internal personal data protection policies and processes to vendors in order for them to be applied to the vendors’ processing of personal data on FHG’s behalf; (d) FHG will enhance its contracts with vendors to include additional data protection obligations, such as the requirement for vendors to undergo regular vulnerability assessments and penetration testing, rights for FHG to audit the vendor’s data processing practices, and requirements for vendors to have in place reasonable data breach response management processes; Agape (e) With the assistance of external cybersecurity consultants, Agape has refreshed its data protection and IT policies; and (f) Agape has increased data protection awareness by requiring employees to go through the assessment tools provided on the Commission’s website, enrolling employees in Workforce Skills Qualifications PDPA courses for certification, and regularly conducting internal communications to maintain cybersecurity vigilance. 15 The Commissioner’s Decision 38 In determining whether any directions should be imposed on FHG and Agape under Section 48I of the PDPA, and/or whether they should be required to pay a financial penalty under Section 48J of the PDPA, the factors listed at Section 48J(6) of the PDPA and the following mitigating factors were taken into account: Mitigating Factors (a) FHG and Agape were cooperative during the investigations; (b) FHG and Agape voluntarily admitted to their breaches of the Protection Obligation under the Commission’s Expedited Decision Procedure; and (c) FHG and Agape took prompt remedial actions following discovery of the Incident. 39 While Agape’s breaches of the Protection Obligation were more causally proximate to the unauthorised access and disclosure of personal data in the Incident, FHG’s inadvertent disclosure of financial and health related data resulted in the impact of the Incident being amplified. As the data controller, FHG also bore the ultimate responsibility to exercise due diligence and reasonable supervision over Agape. For the purposes of assessing what amount of financial penalty would be proportionate and effective as a deterrent, it was also taken into consideration that FHG’s annual turnover based on its latest available audited accounts, was almost 50 times higher than that of Agape’s. 16 40 Having carefully considered all the relevant circumstances, the Commissioner hereby requires that: (a) FHG pay a financial penalty of $58,000; and (b) Agape pay a financial penalty of S$10,000; within 30 days of the date of the relevant notices accompanying this decision, failing which interest at the rate specified in the Rules of Court in respect of judgment debts shall accrue and be payable on the outstanding amount of such financial penalty until the financial penalty is paid in full. 41 In quantifying the financial penalties imposed, no weight was placed on Agape’s status as a social enterprise. The standard of security arrangements expected under the Protection Obligation will depend on the volume and nature of personal data in the organisation’s possession or control, regardless of whether the organisation is a forprofit business, a charity, or a social enterprise5. 42 In addition to the financial penalties imposed, FHG and Agape are also directed to do the following: 5 See Singapore Red Cross Society [2020] SGPDPC 16 at [10] 17 FHG (a) Within 60 days from the date of this decision: i. Review processes and contractual obligations with Agape and existing vendors processing personal data on behalf of FHG, to ensure that such vendors have sufficiently robust data handling processes to protect personal data in their possession and/or control; ii. Review existing internal processes to ensure that only personal data necessary for fulfilling contractual obligations is disclosed to vendors via secured channels and with reasonable access controls considering the type and volume of personal data being disclosed; and (b) Notify the Commission within 14 days of the completion of the reviews above, with an outline of their scope. Agape (c) Within 60 days from the date of this decision: i. Ensure that the scope of its periodic security reviews and any security audits include the protection of personal data handled in all of Agape’s systems and processes; ii. Resolve and record in writing with FHG the data protection requirements and job specifications for the processing of personal data on behalf of FHG, including arrangements for the exercise of regular oversight by FHG to verify that the requirements and specifications are being met; and 18 (d) Notify the Commission within 14 days of the completion of the reviews above, with an outline of their scope. YEONG ZEE KIN DEPUTY COMMISSIONER FOR COMMISSIONER FOR PERSONAL DATA PROTECTION 19 ","Financial Penalty, Directions",1b0b43399e4f4f5d75c72d6a95a144b1fdefd199,"[""tags"",""decision"",""pdf-url"",""description"",""date"",""timestamp"",""url"",""title"",""nature"",""pdf-content""]" 2023-10-01T11:02:10+08:00,fbd32491db44d3d0c97aa12a99cefd61ec954264,6,6,1,1016,"Directions were issued to Kingsforce Management Services to ensure the implementation of regular patching, updates and upgrades for all software and firmware supporting its website(s) and application through which personal data in its possession may be accessed.","[""Protection"", ""Directions"", ""Employment"", ""Protection"", ""Patching""]",2023-05-11,https://www.pdpc.gov.sg/-/media/Files/PDPC/PDF-Files/Commissions-Decisions/GD_KingsforceManagementServicesPteLtd_100323.pdf,Protection,Breach of the Protection Obligation by Kingsforce Management Services,https://www.pdpc.gov.sg/all-commissions-decisions/2023/05/breach-of-the-protection-obligation-by-kingsforce-management-services,2023-05-11,"PERSONAL DATA PROTECTION COMMISSION [2023] SGPDPCS1 Case No. DP-2202-B9480 In the matter of an investigation under section 50(1) of the Personal Data Protection Act 2012 And Kingsforce Management Services Pte Ltd SUMMARY OF THE DECISION 1. On 31 January 2022, the Personal Data Protection Commission (the “Commission”) was notified by Kingsforce Management Services Pte Ltd (the “Organisation”) of the sale on RaidForums, on or about 27 December 2021, of data from its jobseeker database (the “Incident”). 2. The affected database held approximately 54,900 jobseeker datasets, comprising name, address, email address, telephone number, date of birth, job qualifications, last and expected salary, highest qualification and other data related to job searches. 3. External cyber security investigators identified outdated website coding technology, with critical vulnerabilities, as the cause of the Incident. 4. The Commission accepted the Organisation’s request for handling under the Commission’s expedited breach decision procedure. The Organisation voluntarily provided and unequivocally admitted to the facts set out in this decision, and to breach of section 24 of the Personal Data Protection Act (“the PDPA”). 5. The Organisation admitted work had not been completed on the website at launch owing to contractual disputes with the developer. The Organisation subsequently engaged IT maintenance vendors in an effort to ensure the security of the website. However, maintenance had been ad-hoc and limited to troubleshooting functionality issues from bugs, glitches and/or when a page failed to load. 6. In breach of the Protection Obligation, the Organisation failed to provide sufficient clarity and specifications to its vendors on how to protect its database and personal data. In Re Civil Service Club, the Commission had pointed out that organisations that engage IT vendors can provide clarity and emphasize the need for personal data protection to their IT vendors by a) making it part of their contractual terms, and b) reviewing the requirements specifications to ensure that personal data protection is reflected in the design of the end-product.1 Further, post-execution of the contract, an organization is also expected to exercise reasonable oversight over its vendor during the course of the engagement to ensure that the vendor is protecting the personal data by adhering to the stipulated requirements.2 1 Re Civil Service Club [2020] SGPDPC 15. 2 Re WTS Automotive Services Pte Ltd [2019] PDP Digest 317 at [16] and [17]. 7. Another breach of the Protection Obligation by the Organisation was failure to conduct reasonable periodic security reviews, including vulnerability scans, since the launch of its website. The requirement for and scope of reasonable periodic security reviews had long been established in the published decisions of the Commission.3 The PDPC’s Guide to Data Protection Practices for ICT Systems also emphasized the need to periodically conduct web application vulnerability scanning and assessments, post deployment, as a basic practice to ensure compliance with the Protection Obligation under the PDPA.4 8. The Organisation is therefore found to have breached the Protection Obligation under section 24(a) of the PDPA. 9. In deciding the enforcement action in this case, the Commission considered the Organisation’s efforts towards website security, cooperation throughout the investigation, voluntary admission of breach of the Protection Obligation and the prompt remediation taken. The last included immediate suspension of its website, and the engagement of a new developer to develop a new and enhance web application. The Commission also notes that the affected personal data was no longer or accessible following the shutdown of RaidForums. In the circumstances, the Commission directs the Organisation to do the following: a. To submit to the Commission, within twenty-one (21) days from the date of issue of this Direction, a plan to ensure regular patching, updates and upgrades 3 See, eg, Re WTS Automotive Services Pte Ltd [2019] PDP Digest 317; Re Bud Cosmetics Pte Ltd [2019] PDP Digest 351; and Re Watami Food Service Singapore Pte Ltd [2019] PDP Digest 221. 4 Pages 21 and 22 of the Guide to Data Protection Practices for ICT Systems. for all software and firmware supporting its website(s) and applications through which personal data in its possession may be accessed. b. To state whether it intends to implement the plan by engagement of qualified external services or by relying on its own resources, and if by engagement of qualified external services, to state in detail the job specifications for software and firmware patching, updates, and upgrades to be stipulated to the vendor. c. To outline each implementation step with deadlines to ensure that the entire implementation is completed within sixty (60) days from the date of issue of this Direction. The following is the provision of the Personal Data Protection Act 2012 cited in the above summary: Protection of personal data 24. An organisation shall protect personal data in is possession or under its control by making reasonable security arrangements to prevent(a) unauthorized access, collection, use, disclosure, copying, modification or disposal, or similar risks; and (b) the loss of any storage medium or device on which personal data is stored. ",Directions,55f101a661c1696120dbd78b07f569b7bba4c9db,"[""tags"",""decision"",""pdf-url"",""description"",""date"",""timestamp"",""url"",""title"",""nature"",""pdf-content""]" 2023-10-01T11:02:10+08:00,fbd32491db44d3d0c97aa12a99cefd61ec954264,7,7,1,1016,"A financial penalty of $8,000 was imposed on Fortytwo for failing to put in place reasonable security arrangements to protect the personal data in its possession. Fortytwo was also issued directions to complete the upgrading of its website to a supported software version, including vulnerability assessment and penetration testing.","[""Protection"", ""Financial Penalty"", ""Directions"", ""Wholesale and Retail Trade"", ""Patching""]",2023-05-11,https://www.pdpc.gov.sg/-/media/Files/PDPC/PDF-Files/Commissions-Decisions/GD_FortyTwo070323.pdf,Protection,Breach of the Protection Obligation by Fortytwo,https://www.pdpc.gov.sg/all-commissions-decisions/2023/05/breach-of-the-protection-obligation-by-fortytwo,2023-05-11,"PERSONAL DATA PROTECTION COMMISSION [2023 SGPDPCS 3] Case No. DP-2112-B9354 In the matter of an investigation under section 50(1) of the Personal Data Protection Act 2012 And Fortytwo Pte. Ltd. SUMMARY OF THE DECISION 1. On 24 December 2021, Fortytwo Pte. Ltd. (the “Organisation”), an online furniture store, notified the Personal Data Protection Commission (the “Commission”) of malicious code injections on its website which led to the capturing of the email address and password of 6,241 individuals when they logged in to its website (the “Incident”). The name, credit card number, expiry date and CVV/CVN number of another 98 individuals’ were also affected. 2. The Organisation requested for the matter to be handled under the Commission’s expedited breach decision procedure. This means that the Organisation voluntarily provided and unequivocally admitted to the facts set out in this decision; and admitted that it was in breach of section 24 of the Personal Data Protection Act (the “PDPA”). 1 3. An issue that arose in this case is whether fictitious names or pseudonymous personal particulars form part of the personal data under the possession or control of the Organisation. The importance of this lies in how it may potentially reduce the size of the dataset that was at risk. In their addendum to the Written Statement, the Organisation stated that it does not verify the names provided by the users, and suggested that the impact of the Incident might be more limited as some of the users’ names may be incomplete, fictitious or pseudonymous. 4. Section 2(1) of the PDPA defines “personal data” to be data, whether true or not (emphasis added), about an individual who can be identified from that data; or from that data and other information to which the organisation has or is likely to have access. The PDPA caters for the situation where not every record of personal data that is under the possession or control of an Organisation is verified. It takes a practical approach, as the accuracy of personal data records will change with the passage of time (e.g. information becomes outdated) or individuals may intentionally provide inaccurate information (e.g. users hiding their age or using fictitious residential addresses to bypass restriction of services by age or geolocation). What matters is that the Organisation, having collected the information, takes steps to comply with their obligations under the PDPA, such as to protect them and to ensure that they are used in accordance with the purpose of their collection. 5. The situation is different when the organisation, as a data security or data management measure, applies pseudonymisation or anonymisation techniques on personal data that is in their possession or under their control. In such circumstances, if the risk of reidentification is adequately addressed and managed, the resulting dataset may be treated as anonymised. The key difference is the intention of the 2 organisation and its ability to direct and control the data processing activities required to achieve the resultant anonymised dataset.1 6. In this case, the Organisation was collecting data from its customers. Their customer database contained names, email addresses and additional details such as their shipping address, billing address, and date of birth. It also contained credit card details of 98 customers. Even if some customers had provided incomplete, fictitious or pseudonymous personal particulars or payment details, the Organisation had collected personal data. For the purpose of this investigations, it matters not that some of these customers may have provided inaccurate information. The Organisation’s obligations under the PDPA applies to the entire customer database. 7. The Organisation admitted that the Incident occurred because the threat actor had successfully exploited vulnerabilities present in the Magento open-source version 1.9.x.x which the Organisation had employed for its online store. These vulnerabilities were present because the Organisation failed to apply four Magento security patches released on 28 Nov 2017, 25 June 2019, 8 October 2019 and 28 April 2020 by Adobe. 8. Compounding the above, support for Magento version 1 had ended on 30 June 2020. The Organisation admitted that it should have upgraded to Magento opensource version 2.0 after Adobe ended the support for Magento 1 on 30 June 2020. The Organisation had planned to upgrade to Magento version 2 in early 2020, but its plans were disrupted by the COVID-19 pandemic. Having said that, Adobe had announced in November 2015 that it will end support for Magento 1.x in 36 months, 1 See Personal Data Protection Commission, Advisory Guidelines on the Personal Data Protection Act for Selected Topics, at paras 3.5, 3.8 and 3.13. 3 i.e. by November 2018. In September 2018, Adobe then announced that it would extend the support to 30 June 2020. Given the ample notice given by Adobe to the Organisation of the need to upgrade the version of Magento Open Source which it was using in order to continue receiving support and security patches from Adobe, it is difficult to look past the Organisation’s prolonged failure to do the needful and perform the necessary upgrades. 9. The Commission had consistently advised organisations on the importance of applying software patches. In our Guide to Data Protection Practices for ICT Systems, the Commission had highlighted that organisations should perform system patching promptly to fix security vulnerabilities. If software patches are not updated as recommended by the software provider, they may not contain the latest cybersecurity updates and may compromise the organisation’s defence against cyber-attacks. 10. We note that the Organisation had considered and evaluated the four patches but decided to hold back on installing them. However, these four patches were released by Adobe to address several high severity risk issues and critical bugs, including the injection of malicious codes. The Organisation’s failure to patch had increased the risks of a malicious code injection capable of capturing users’ personal data. 11. In light of the above, the Organisation is found to have breached the Protection Obligation under section 24(a) of the PDPA. 4 12. The Commission notes that after the Incident, the Organisation took prompt remedial actions, including notifying affected individuals and various technical measures to improve its security. The Organisation is also taking steps to upgrade to Magento version 2. 13. In deciding the appropriate outcome in this case, the Commission considered the Organisation’s cooperation throughout the investigation, the voluntary admission of breach of the Protection Obligation, and the prompt remedial actions taken. 14. Following the issuance of the Commission’s preliminary decision, the Organisation represented that it was unfair to state that was a prolonged failure to perform the necessary upgrade. This is because there was a lead time of 6 months before the end of support when it made the decision to upgrade, before the COVID19 pandemic disrupted its plans. The Organisation’s representation is not accepted as, notwithstanding the disruptions caused by the pandemic, the Organisation had been given ample notice of the impending end of support but took no action to perform the necessary upgrade from November 2015 to early 2020. 15. Having considered the circumstances set out above, the factors listed at section 48J(6) of the PDPA and the representations made by the Organisation, the Deputy Commissioner for Personal Data Protection hereby finds the Organisation in breach and directs the Organisation to pay a financial penalty of S$8,000 within 30 days from the notice accompanying date of this decision, failing which interest at the rate specified in the Rules of Court in respect of judgement debts shall accrue and be 5 payable on the outstanding amount of such financial penalty until the financial penalty is paid in full. 16. The Organisation is also directed to: a. Complete the upgrading of its website to a supported software version, including vulnerability assessment and penetration testing, within 6 months of the direction. b. Inform the Commission with 14 days of the completion of the above. The following is the provision of the Personal Data Protection Act 2012 cited in the above summary: Protection of personal data 24. An organisation shall protect personal data in its possession or under its control by making reasonable security arrangements to prevent – (a) unauthorised access, collection, use, disclosure, copying, modification, disposal or similar risks; and (b) the loss of any storage medium or device on which personal data is stored. 6 ","Financial Penalty, Directions",94a50b28e4364bbb6e7cc57412b04d7d6841f870,"[""tags"",""decision"",""pdf-url"",""description"",""date"",""timestamp"",""url"",""title"",""nature"",""pdf-content""]" 2023-10-01T11:02:10+08:00,fbd32491db44d3d0c97aa12a99cefd61ec954264,8,8,1,1016,"Directions were issued to The Law Society of Singapore to conduct a security audit of its technical and administrative arrangements for accounts with administrative privileges that can access directly and/or create access to personal data, and to rectify any gaps identified. This is pursuant to a data breach incident where The Law Society’s servers were subjected to a ransomware attack.","[""Protection"", ""Directions"", ""Professional"", ""Scientific and Technical"", ""Ransomware"", ""Patching"", ""Security"", ""Password""]",2023-05-11,https://www.pdpc.gov.sg/-/media/Files/PDPC/PDF-Files/Commissions-Decisions/GD_LawSocietyofSingapore_140323.pdf,Protection,Breach of the Protection Obligation by The Law Society of Singapore,https://www.pdpc.gov.sg/all-commissions-decisions/2023/05/breach-of-the-protection-obligation-by-the-law-society-of-singapore,2023-05-11,"PERSONAL DATA PROTECTION COMMISSION [2023] SGPDPC 4 Case No. DP-2102-B7850 In the matter of an investigation under section 50(1) of the Personal Data Protection Act 2012 And The Law Society of Singapore … Organisation DECISION 1 The Law Society of Singapore Yeong Zee Kin, Deputy Commissioner — Case No. DP-2102-B7850 14 March 2023 Introduction 1 On 4 February 2021, the Law Society of Singapore (the “Organisation”) notified the Personal Data Protection Commission (the “Commission”) of a ransomware attack on its servers which had encrypted and denied the Organisation access to the personal data of its members and former members (the “Incident”). The Commission commenced investigations to determine whether the circumstances behind the Incident disclosed any breaches by the Organisation of the Personal Data Protection Act 2012 (“PDPA”). Facts of the Case 2 The Organisation is a body corporate established under the Legal Profession Act 1966 and represents members of the legal profession in Singapore. Every advocate and solicitor called to the Singapore bar is a statutory member of the Organisation as long as they have a practising certificate in force. At the material time, the Organisation stored the personal data of its current and former members (“Members”) in one of its servers for the purposes of carrying out its statutory functions. 2 3 The Organisation had implemented an off-the-shelf secure VPN solution, FortiOS, to manage remote access to its servers (the “VPN System”). The Organisation also engaged a vendor (the “Vendor”) to provide IT support services, including maintenance of the VPN System. For completeness, the Vendor was not the Organisation’s data intermediary as it did not access or process the personal data of the Members in the course of carrying out its IT support services. 4 The Organisation also implemented antivirus / malware detection software at the servers, and password complexity requirements for its users’ accounts. In particular, account passwords had a maximum lifespan of 3 months before a compulsory change was required. 5 Additionally, the Organisation had in place a written data protection policy and conducted data protection training for its staff highlighting cybersecurity threats such as phishing and ransomware. Periodic emails on data protection awareness and reminders were also sent to staff. The Incident 6 On 27 January 2021, a threat actor gained access to the account of the Organisation’s IT administrator (“compromised admin account”) and used this to create a new account with full administrative privileges. Using this new account, the threat actor moved through the Organisation’s network without detection and located the Organisation’s servers. The threat actor then executed a ransomware attack on the servers, encrypting their contents. 3 7 A total of 16,009 Members’ personal data was affected in the Incident, including each Member’s full name, residential address, date of birth, and NRIC number. Other data items were also affected but they are either in the nature of business contact information or publicly available information. 8 The attack was detected on the same day by antivirus / malware detection software deployed by the Organisation. The Organisation took immediate steps to remove the new administrator account created by the threat actor and restored the servers to their original state from secured back-ups. Remedial actions 9 Following the Incident, the Organisation also took the following remedial actions: (a) Removed unused administrator accounts and initiated password resets for all administrator accounts; (b) Reduced privileged access for the compromised admin account (to create new administrator accounts); (c) Hired an in-house cybersecurity professional to take charge of the Organisation’s IT security matters; (d) Implemented multi-factor authentication (“MFA”) for all VPN access; and (e) Implemented VPN IP location whitelisting to allow only Singapore-based IP addresses. Findings and Basis for Determination 4 10 The Commission’s investigation centred on whether the Organisation had breached its obligation under Section 24 of the PDPA to protect personal data in its possession or under its control by making reasonable security arrangements to prevent unauthorised access, collection, use, disclosure, copying, modification, disposal or similar risks (the “Protection Obligation”). As the Vendor was not the Organisation’s data intermediary, the Protection Obligation in this case was borne solely by the Organisation. Findings from the investigations 11 Investigations disclosed that there could have been multiple threat actors targeting the Organisation or the same group of threat actors targeting the Organisation through multiple channels – through brute force attacks, phishing email, and exploiting the unpatched VPN vulnerability of the VPN System. 12 Brute-force attacks. Around ten days before the Incident, multiple unsuccessful login attempts using a “guest” account were found since 18 January 2021. There were also further unsuccessful attempts made using random accounts. However, investigations did not surface evidence that the initial entry by the threat actor had been via a successful brute force attack on the compromised admin account. 13 Phishing emails. Investigations also revealed that the Organisation was attacked by the Netwalker ransomware, most commonly introduced via phishing emails. From the Vendor’s explanations, the administrator of the compromised admin account could have received a phishing email with a link and entered his credentials. However, investigations did not surface evidence of any phishing email relevant to this 5 ransomware; neither was there evidence that the compromised admin account’s credentials was obtained by a threat actor through phishing. 14 Vulnerability of the VPN System. At the material time before the Incident, MFA was not implemented for the Organisation’s administrator access to its servers. This meant that once authenticated, an admin user had rights to create new accounts, assign privileged security groups, and access all of the Organisation’s servers without the need for a second factor. 15 Investigations revealed that there was a vulnerability in the VPN System which could be exploited to gain access credentials if left unpatched (the “Vulnerability”). This was assessed to be a possible way in which the threat actor obtained the credentials of the compromised admin account: (a) Around November 2020, a file containing more than 45,000 session links and IP addresses for the VPN System of affected organisations (including the Organisation) was found posted in online forums by someone who had obtained the information by exploiting the Vulnerability. (b) Without patching the VPN System’s firmware, each session link would disclose the credentials of users in plain text, including passwords. (c) The date/time of the online publication (i.e. November 2020) was sufficiently proximate to the threat actor’s successful intrusion in January 2021 using the compromised admin account. 6 16 From the foregoing, it would appear that of the three possible attack vectors, the vulnerability in the VPN System could have given the threat actor entry into the Organisation’s environment. No breach of the Protection Obligation for omission to patch the Vulnerability 17 The developer of the VPN System, Fortinet, had disclosed the Vulnerability as early as 24 May 2019. It released an Operating System (“OS”) upgrade to remedy the issue, which contained the updates to remedy the issue. The VPN System had a user interface (“UI”) through which the OS upgrade availability could be notified. According to the Vendor, the Vendor had regularly checked the UI if OS upgrades were available but there were no prompts of updates available for download prior to the Incident. According to the Organisation, it was only after it communicated the issue to the developer, after the incident, that the UI subsequently prompted availability of some patches that included the OS upgrade remedying the Vulnerability. 18 The Commission recognises that organisations may rely on vendors engaged to provide IT security maintenance to obtain and apply needed software upgrades and patches. If so, the Protection Obligation requires organisations to stipulate such requirements clearly in writing as part of the job specifications of such vendors. In this case, patching of the VPN System had been a specific obligation explicitly outsourced by the Organisation to the Vendor via contract. 19 In addition to clearly stipulating the vendor’s scope of IT maintenance and/or development work, organisations are expected to exercise reasonable oversight over the vendor’s performance of the subcontracted services, including patching – Re 7 Smiling Orchard (S) Pte Ltd and Ors [2016] SGPDPC 191. There should be a clear meeting of minds as to the services the service provider has agreed to undertake and organisations must follow through with procedures to check that the outsourced provider is delivering the services. 20 The Commission appreciates that the technical nature of information on software patching and upgrades limits the degree of oversight that many organisations can exercise on vendor performance in this regard. The Commission notes that the Organisation had put in place a process to ensure that there were maintenance logs in respect of the Vendor’s activities. Thus, the Organisation, to its credit, had put in place a system to monitor its Vendor’s activities. In technical areas where the Organisation depends on its Vendor’s technical expertise, this is reasonably adequate. The situation may be different if there was a very well-publicised issue with a wellknown commercial solution (e.g. vulnerabilities affecting a network router) that the Organisation ought to know that it uses. In such situations, the Organisation might be at least expected to query its Vendor about whether it is exposed and ask for a remediation plan. But this is probably limited to well-known and well-publicised issues in mass media. 21 Carefully weighing the above circumstances, the Commission has decided that: (a) it had been reasonable for the Organisation to rely on the Vendor to perform software security patching, including of the Vulnerability, and (b) that the Organisation 1 See also Singapore Health Services Pte. Ltd and Integrated Health Information Systems Pte Ltd [2019] SGPDPC 3. 8 had in this case discharged its duty of oversight of the Vendor’s patching function. Therefore the Organisation has not breached the Protection Obligation. Breach of the Protection Obligation by the Organisation in other aspects 22 Investigations revealed that the password for the compromised admin account was “Welcome2020lawsoc”. Despite this password complying with the Organisation’s own password complexity rules, the Organisation acknowledged that this was a weak password and vulnerable to dictionary attacks due to the use of a full word and the Organisation’s name. As highlighted in Chizzle Pte Ltd [2020] SGPDPCR 1, a password that meets complexity rules in form could still be regarded as a weak password if it was easily determined and vulnerable to brute force attacks. In that case, the password “Chi!zzle@2018” incorporated the organisation’s name and was determined to be a weak password. Further, the Organisation informed that the compromised admin account’s password had been used for more than 90 days and had not been changed every 3 months, as required by the Organisation’s password policy. In the circumstances, the Organisation failed to enforce its password policy in relation to the compromised admin account. 23 In the Commission’s recent Guide to Data Protection Practices for ICT systems2, it has been observed that unauthorised access is one of the most common types of data breaches. This can happen, for example, through the use of a weak password which is easily guessed by hackers. To remediate this, it may be practical to look into implementing processes in ICT systems to minimise risk of brute force 2 Published on 14 September 2021, replacing the Guide to Data Protection by Design for ICT systems published on 31 May 2019, after the Incident. 9 attacks (e.g. a pre-defined number of failed login attempts) and ensure information is accessed only by the authorised/authenticated persons performing the intended activities. Additionally, as 2FA or MFA becomes more broadly available, the adoption of these tools should become the norm for accounts with administrative privileges, for systems managing sensitive data or large volumes of personal data3. 24 Next, the Organisation also did not conduct a review of its security arrangements within the last 3 years prior to the Incident. Regular assurance checks help organisations ensure that ICT security controls developed and configured for the protection of personal data are properly implemented and practised4. In Re WTS Automotive Services Pte Ltd [2018] SGPDPC 265, the Commission emphasised (at [18]) for the need for regular review of security arrangements and tests to detect vulnerabilities. 25 For the above reasons, the Organisation is found to have negligently breached the Protection Obligation by (i) using an easily guessable password for the compromised admin account, (ii) failing to change the password for the compromised admin account at reasonable intervals, and (iii) failing to conduct any periodic security reviews in the three years leading up to the Incident. 3 See the Commission’s recent release of the handbook on common causes of data breaches in How to Guard against Common Types of Data Breaches published on 24 May 2021 (at page 13), after the Incident; See Love Bonito Singapore Pte Ltd [2022] SGPDPC 3. 4 See the Guide to Data Protection Practices for ICT systems. 5 See also Jigyasa [2020] SGPDPC 9. 10 The Deputy Commissioner’s Decision 26 Notwithstanding that the Organisation’s breaches of the Protection Obligation were not directly related to the Incident, the Commission’s role is not limited to investigating only the immediate or proximate causes of a data breach incident 6. In determining whether directions (if any) should be given to the Organisation pursuant to Section 48I of the PDPA, and/or whether a financial penalty ought to be imposed pursuant to Section 48J of the PDPA, the Deputy Commissioner took into consideration the relevant facts and circumstances of the case, and in particular the following factors: (a) The Organisation’s breaches of the Protection Obligation were not the most proximate cause of the Incident (which was the VPN Vulnerability); (b) The datasets affected in the Incident were not of a higher sensitivity (e.g. personal data of a financial or medical nature); (c) The risk of unauthorised access to the Members’ personal data was limited due to early detection of the unauthorised access, which also allowed prompt containment and restoration of the servers to its original state; (d) There was no evidence of any exfiltration or misuse of the personal data of the Members; and (e) 27 The Organisation took prompt remedial actions in response to the Incident. For the above reasons, it is adequate for directions to be issued in this case. The Deputy Commissioner hereby directs the Organisation to: (a) Engage qualified security service providers to conduct a thorough security audit of its technical and administrative arrangements for the security, 6 See Love Bonito Singapore Pte Ltd [2022] SGPDPC 3. 11 maintenance, creation and removal of accounts with administrative privileges that can access directly and/or create access to personal data in the possession or control of the Organisation; (b) Furnish to the Commission within 14 days a schedule stating the scope of the security audit; (c) Provide the full security audit report to the Commission, by no later than 60 days from the date of the issue of this direction; (d) Rectify any security gaps identified in the security audit report, review and update its personal data protection policies as applicable, and (e) Inform the Commission within 1 week of completion of rectification and implementation in response to the security audit report. YEONG ZEE KIN DEPUTY COMMISSIONER FOR PERSONAL DATA PROTECTION 12 ",Directions,7d6096f9562cfde74f556a2117cc264960050a02,"[""tags"",""decision"",""pdf-url"",""description"",""date"",""timestamp"",""url"",""title"",""nature"",""pdf-content""]" 2023-10-01T11:02:10+08:00,fbd32491db44d3d0c97aa12a99cefd61ec954264,9,9,1,1016,"A financial penalty of $37,000 was imposed on OrangeTee & Tie for failing to put in place reasonable security arrangements to protect users' personal data in its possession or under its control.","[""Protection"", ""Financial Penalty"", ""Real Estate""]",2023-04-17,https://www.pdpc.gov.sg/-/media/Files/PDPC/PDF-Files/Commissions-Decisions/GD_OrangeTee_210223.pdf,Protection,Breach of the Protection Obligation by OrangeTee & Tie,https://www.pdpc.gov.sg/all-commissions-decisions/2023/04/breach-of-the-protection-obligation-by-orangetee-and-tie,2023-04-17,"PERSONAL DATA PROTECTION COMMISSION [2023] SGPDPC 3 Case No. DP-2108-B8712 In the matter of an investigation under section 50(1) of the Personal Data Protection Act 2012 And OrangeTee & Tie Pte Ltd … Organisation DECISION OrangeTee & Tie Pte Ltd Lew Chuen Hong, Commissioner — Case No. DP-2108-B8712 21 February 2023 Introduction 1 On 4 August 2021, the Personal Data Protection Commission (“Commission”) contacted OrangeTee & Tie Pte Ltd (“Organisation”) after receiving information indicating that a threat actor had managed to exfiltrate databases in the Organisation’s possession, which were believed to contain personal data. 2 Subsequently, on 6 August 2021, the Organisation notified the Commission of an incident involving unauthorised access to its IT network (the “Incident”). The Organisation also gave a media statement on the same day informing members of the public about the Incident and inviting any concerned customers to contact the Organisation’s call centre for clarification. 3 The Commission then commenced investigations to determine the Organisation’s compliance with the Personal Data Protection Act 2012 (“PDPA”) in relation to the Incident. Facts of the Case 4 The Organisation is a real estate enterprise based in Singapore and has been in operation since 2000. 5 Four servers maintained by the Organisation were involved in the Incident, namely: the Production Web Server, the Production Database Server, the Development Web Server, and the Development Database Server. The Production Web Server and the Development Web Server (collectively the “Web Servers”) were internet-facing, in that they were directly accessible from the internet. The Production Web Server was linked to the Production Database Server, while the Development Web Server was linked to the Development Database Server. 6 The personal data of employees and customers of the Organisation was stored on the Production Database Server and the Development Database Server (collectively the “Database Servers”). The personal data had not been encrypted. 7 The Databases Servers were running Microsoft SQL Server 2012 Standard version 11.0.6251.0 (Service Pack 3) at the time of the Incident, which Microsoft had ceased support for on 9 October 2018. Additionally, the version of Microsoft SQL Server the Organisation used was also not updated, as the most current Service Pack 4 was not installed. The Incident 8 On 3 August 2021, the Organisation received a ransom demand email from an organisation which identified themselves as ‘ALTDOS’. The email was sent from an email address which is known to be used by the ALTDOS group. The threat actor claimed that they had been hacking the Organisation’s network since June 2021 and had stolen “hundreds of databases”, some of which were claimed to contain sensitive information. The ransom demand also contained video footage of five databases purported to have been stolen, which showed that sensitive data might have been exfiltrated from the Organisation’s servers. 9 In the same email, the threat actor demanded a ransom of 10 Bitcoins for the safety and non-disclosure of the exfiltrated databases and threatened disclosure if the ransom was not paid. The Organisation filed a police report and reported the Incident to the Singapore Computer Emergency Response Team, a division of the Cyber Security Agency of Singapore. 10 On 4 August 2021, having not received the demanded ransom, ALTDOS carried out a Distributed Denial-of-Service attack which brought down the Organisation’s network, and sent an additional ransom demand via email and WhatsApp to some of the Organisation’s employees. 11 The Organisation engaged a private forensic expert (“PFE”) to ascertain the cause and extent of the Incident. PFE’s investigations disclosed that, contrary to their claims, the threat actor exfiltrated personal datasets from eleven databases, containing personal data set out in the table below: Category of Number of Individuals Individuals Employees 305 Types of Personal Data Affected Name, full NRIC/FIN/passport number and bank account number Customers 245,752 Name, full NRIC/FIN/passport number and property transaction amount Agents 10,526 1. Name, full NRIC/FIN/passport number and bank account number (2,301 individuals) 2. Name, full NRIC/FIN number, bank account number and commission amount (4,763 individuals) 3. Name, full NRIC/FIN number, commission amount (286 individuals) 4. Name, full NRIC/FIN number (3,176 individuals) TOTAL 12 256,583 - The PFE’s investigations found that the threat actor had carried out certain web- based attacks and exploited vulnerabilities on the Web Servers to successfully exfiltrate databases from the outdated Database Servers. The following observations were made by the PFE: (a) Production Web Server – the PFE concluded that the threat actor used SQL injection attacks on the Production Web Server. SQL injections are a way of exploiting vulnerable website code and forms to return data from a SQL database that should not be available to a user. The PFE also found that the threat actor had likely used a malicious tool known as ‘SQL Map’ on vulnerable webpages in the Production Web Server, to automate the systematic probing of webpages for SQL injection vulnerabilities. Once the vulnerabilities were discovered, the threat actor then proceeded to exploit the vulnerabilities to access and exfiltrate data from four databases within the Production Database Server at some point(s) between 24 June 2021 and 3 August 2021. (b) Development Web Server – the PFE could not locate forensic artefacts to confirm the mode of attack by the threat actor. However, the PFE identified evidence of cross-site scripting attacks. Cross-site scripting attacks involve the injection of malicious scripts into trusted websites which are then executed on end-users’ browsers. In this case, malicious code had been injected into the Development Web Server. This led the PFE to believe that the Development Web Server was compromised. The threat actor is believed to have exploited the compromised Development Web Server to access and exfiltrate data from seven databases on the Development Database Server, although it was unclear how and when this had occurred. Remedial actions 13 Following the Incident, the Organisation implemented the following remedial measures: Immediate remedial steps to contain the Incident (a) Shut down and isolated the affected servers from the rest of the IT network; (b) Updated its servers with the latest security patches; To prevent recurrence or similar incidents (c) Tested the affected servers for vulnerabilities and deployed enterprisegrade anti-malware software across the IT network; (d) Carried out security hardening activities, including the removal of redundant services, restricting access and services, and ensuring the server is secure to ‘Center for Internet of Security’ (CIS) benchmarking standards; (e) Carried out detailed analysis of intrusion prevention logs; (f) Reviewed and secured the firewall configuration; (g) Separated the public-facing website from the internal agent portal and ensured that the former was securely hosted; (h) Implemented a web application firewall to protect the network; and (i) Liaised with the PFE on the recovery process as well as improving IT security. Findings and Basis for Determination 14 Based on the circumstances of the Incident, the Commission’s investigation centred on whether the Organisation had breached its obligation under section 24 of the PDPA to protect personal data in its possession or under its control by making reasonable security arrangements to prevent unauthorised access, collection, use, disclosure, copying, modification, disposal, or similar risks (the “Protection Obligation”). The Organisation was determined to have breached the Protection Obligation in the following two respects. Use of production data in Development Servers for testing purposes 15 First, the Organisation used ‘live’ production data for development and testing purposes without sufficiently robust processes to protect the personal data through proper safeguards. 16 The ‘live’ production data used included personal data and had been stored in the development environment (i.e. the Development Servers) from which the datasets had been exfiltrated by the threat actor. The Organisation explained the use of ‘live’ production data as being necessary in order for the testing computations to be accurately derived, and for the actual business process flow to be effectively tested. 17 The Commission has advised in its Handbook on How to Guard Against Common Types of Data Breaches (the “Handbook”) at page 11 that use of ‘live’ production personal data for testing creates a security risk. 1 The safer practice would be to use anonymised data for testing purposes. Synthetic data, which is fake data that contains similar characteristics as the real data, is a form of anonymised data. Another way is to use pseudonymised data where direct identifiers have been replaced with pseudonyms. The Commission has explained the rationale for anonymisation of personal data for development and business study in the Advisory Guidelines on the PDPA for Selected Topics: Handbook on How to Guard Against Common Types of Data Breaches (“Handbook”), page 11: “Out of convenience, many organisations use production data for system testing in their test environments. But as test environments tend to be much less secured, there is a high risk of data breach in a test environment.” (https://www.pdpc.gov.sg/news-andevents/announcements/2021/05/handbook-on-how-to-guard-against-common-types-of-data-breaches-now-available) 1 “3.14 Anonymisation of personal data enables businesses to tap on data for insights and innovation while at the same time provides protection to individuals. It also reduces the impact of harm to individuals in the event of a data breach. Where possible, Organisations should adopt such practices for external sharing of data. It can even be adopted when sharing data internally, particularly where individuals need not be identified for the purposes of processing. 3.15 In the event of a data breach, the level of data anonymisation, corresponding safeguards implemented and proper assessment by organisations in considering the harms of the anonymised data would be taken into consideration to assess if data has been properly anonymised.”2 (emphasis in bold added) 18 The Commission’s position on this issue had been reiterated in Re PINC Interactive Pte Ltd [2022] SGPDPC 1, in which it was held that the organisation had breached the Protection Obligation by using a synthetic dataset that contained personal data belonging to real users. It should have used 100% synthetic data.3 19 However, where the use of ‘live’ personal data is operationally necessary, sufficiently robust processes should be implemented to safeguard the personal data. Testing or development environments are usually not as secured as production environments. The Organisation in this case had failed to implement sufficiently robust Advisory Guidelines on the PDPA for Selected Topics, page 14, paragraphs 3.14 – 3.15 (https://www.pdpc.gov.sg/guidelinesand-consultation/2020/02/advisory-guidelines-on-the-personal-data-protection-act-for-selected-topics) 3 Re PINC Interactive Pte Ltd [2022] SGPDPC 1, [10] – [12] 2 processes in the form of a security assessment of the risk from using, and storing, ‘live’ personal data in a testing environment. Such a security assessment could consider, for example, whether to restrict access to a smaller group of testers and limit the duration when live data is loaded in the testing environment. If the testing environment is accessible from the Internet, security assessment ought to also be carried out of the risk of unauthorised web entry. 20 Without such an assessment, the Organisation was not positioned to make an informed decision on whether the security arrangements to protect the personal data had been reasonable or had needed to be enhanced. The lack of sufficiently robust processes to protect personal data through proper safeguards, such as the conduct of a reasonable security assessment, amounted to a breach of the Protection Obligation by the Organisation. Failure to conduct reasonable periodic security reviews prior to the Incident 21 Second, the Organisation failed to conduct reasonable periodic security reviews for its servers. 22 The Commission’s previous decisions4 and the Guide5 have established that periodic security reviews should be conducted to a reasonable standard to identify and remedy any vulnerabilities. Such scheduled reviews should be in place as a basic practice as it would likely have resulted in the detection of the vulnerabilities arising from the outdated software and the risk of SQL injection techniques. The Organisation 4 5 WTS Automotive Services Pte. Ltd. [2018] SGPDPC 26 and Commeasure Pte Ltd [2021] SGPDPC 11 Guide, page 21, paragraph (g) admitted in its submissions to the Commission that it had not considered the need for such security reviews in its IT security policy. 23 Both Web Servers were internet-facing and were connected to production data stored in both Database Servers, thereby exposing the ‘live’ production data contained therein (containing personal data) to security risks. However, owing to its failure to conduct periodic security reviews for the Web and Database Servers, the Organisation did not recognise the risks engendered by the outdated software and did not take steps to assure itself that all internet-facing servers were adequately protected. Had the Organisation conducted reasonable periodic security reviews prior to the Incident, the vulnerabilities to SQL injection techniques in the Web Servers would have been known and remedied. The Incident could then very likely have been avoided. 24 For the above reasons, the Organisation was determined to have breached the Protection Obligation by (i) using personal data belonging to real users in a development environment (i.e. the Development Servers) without a sufficiently robust process for a reasonable security assessment of the risk, and (ii) failing to conduct reasonable security reviews prior to the Incident. Organisation’s position on the failure to update Microsoft SQL Server 2012 25 The Organisation explained its failure to update the Database Servers’ Microsoft SQL Server 2012 version and install Service Pack 4 as follows: (a) The Organisation’s IT team relied on Microsoft’s own auto-scan function to be alerted to available updating patches as a prompt for installation. This Microsoft tool ran once a month before the Incident. The tool, however, failed to detect that the installed version of Microsoft SQL Server 2012 in the servers required patching, and that the required patch in the form of Service Pack 4 had been available. (b) The tool had not previously failed to detect and alert about required updates. (c) The alternative option of requiring the IT team to conduct a manual review of all updates released by Microsoft every month had not been practical or reasonable as compared to relying on the auto-scan function. (d) The Organisation’s IT team did not use third-party scanning software to monitor and detect available patches because even these might not have identified the need to patch Microsoft SQL Server 2012 with Service Pack 4. 26 The Commission’s investigation revealed no known issues relating to the availability or installation of Microsoft SQL Server 2012 Service Pack 4 updates. The Protection Obligation required the Organisation to have sufficiently robust processes to protect personal data through regular patching / updates / upgrades of important software. The question is whether the Organisation’s reliance on system prompts in the form of alerts from the Microsoft auto-scan function had amounted to a sufficiently robust process for patching in the circumstances of this case. 27 Service Packs are significant collations of updates and patches that have been released. When released, Service Packs effectively provide a new baseline of updates and patches. On the question above, the Commission noted that the Microsoft Knowledge Base site indicated that the Service Pack 4 update had been available through the usual Windows Update auto-scan function since October 2017. This means that it would have been available for almost 4 years at the time of the Incident. Considering that an important software patch in the form of the Service Pack 4 had in this case been available for almost 4 years, the Organisation’s reliance on system prompts such as alerts through the auto-scan function had not been a sufficiently robust process to patch important software for the security of personal data. The Organisation should be aware of significant Service Packs and consciously decide whether to upgrade. The Commissioner’s Decision 28 In determining whether to impose a financial penalty on the Organisation pursuant to section 48J(1) of the PDPA, and the amount of any such financial penalty, the matters set out at section 48J(1), and the factors listed at section 48J(6) of the PDPA were taken into account, including the following mitigating factors: Mitigating Factors (a) The Organisation took prompt remedial actions, including notifying the affected individuals; (b) The Organisation was cooperative during investigations; and (c) The Organisation voluntarily admitted that it had breached the Protection Obligation in Section 24(a) of the PDPA in failing to protect personal data in its possession by making reasonable security arrangements to prevent unauthorised access. 29 The Commission further notes that names and property transaction amounts were among the categories of personal data which was exfiltrated. Whilst the Commission took the exfiltration of such personal data into account in its decision, it does not consider these categories to be highly sensitive in nature as this information is, to a certain extent, already in the public domain. For example, a member of the public is able to look up such information through a land titles search on the Singapore Land Authority website (for names), or a search on the Urban Redevelopment Authority website for caveats lodged (for property transaction amounts). Thus, this information is publicly available as defined in s 2(1) of the PDPA. 30 Having considered all the relevant circumstances of this case, the Commissioner hereby requires the Organisation to pay a financial penalty of $37,000 within 30 days from the date of the relevant notice accompanying this decision, failing which interest at the rate specified in the Rules of Court in respect of judgment debts shall accrue and be payable on the outstanding amount of such financial penalty until the financial penalty is paid in full. 31 No further directions are necessary on account of the remedial measures already taken by the Organisation. YEONG ZEE KIN DEPUTY COMMISSIONER FOR COMMISSIONER FOR PERSONAL DATA PROTECTION ",Financial Penalty,bc2f44656c288eb64e8e9ad0568ae8dadb65e251,"[""tags"",""decision"",""pdf-url"",""description"",""date"",""timestamp"",""url"",""title"",""nature"",""pdf-content""]" 2023-10-01T11:02:10+08:00,fbd32491db44d3d0c97aa12a99cefd61ec954264,10,10,1,1016,"A warning was issued to an individual for using dictionary attack methods to generate telephone numbers which were then used for telemarketing purposes, thereby breaching section 48B of the PDPA.","[""Do Not Call Provision(s)"", ""Warning"", ""Others"", ""Telemarketing""]",2023-04-17,https://www.pdpc.gov.sg/-/media/Files/PDPC/PDF-Files/Commissions-Decisions/GD_TaiShinFatt_140223.pdf,Do Not Call Provision(s),Breach of Section 48B of the PDPA (Prohibition on Use of Dictionary Attacks) by an individual,https://www.pdpc.gov.sg/all-commissions-decisions/2023/04/breach-of-section-48b-of-the-pdpa-prohibition-on-use-of-dictionary-attacks-by-an-individual,2023-04-17,"PERSONAL DATA PROTECTION COMMISSION [2023] SGPDPC 2 Case No. ENF-DNC-210826-0015 In the matter of an investigation under section 50(1) of the Personal Data Protection Act 2012 And Tai Shin Fatt … Individual DECISION Tai Shin Fatt Lee Ti-Ting, Assistant Commissioner - Case No. ENF-DNC-210826-0015 14 February 2023 Introduction 1 On 2 July 2021, the Personal Data Protection Commission (“the Commission”) was notified by the Singapore Police Force that the Singapore Civil Defence Force (“SCDF”) had received an influx of marketing calls between 25 and 28 June 2021 from telephone numbers registered to one LongSheng Consultancy Pte Ltd (“LongSheng”) on behalf of one Tai Shin Fatt (the “Individual”). The Commission commenced investigations to determine whether the circumstances relating to the calls disclosed any breaches of the Personal Data Protection Act 2012 (“PDPA”). Facts of the Case 2 The Individual is an insurance director with a large and well-known insurance company managing a team of 25 insurance agents. In an effort to conduct marketing calls more efficiently, the Individual sought to engage the services of 2 companies hereinafter referred to as the “Call Automation Vendor” and the “Checker”. 3 The Call Automation Vendor provides software to facilitate the making of automated calls using customised scripts. The Checker’s service comprises the provision of telephone numbers (from which automated calls could be made), and the provision of software to check whether the telephone numbers of intended recipients were registered with the Do Not Call Registry (“DNCR”). The systems / software of the Call Automation Vendor and the Checker were intended to work in tandem as follows: (a) the telephone numbers of intended recipients would be uploaded onto the Call Automation Vendor’s software; (b) the Checker’s software would check the DNCR for such telephone numbers; and (c) the Call Automation Vendor’s software would then avoid making any calls to the telephone numbers which appeared in the DNCR. 4 As the Call Automation Vendor and the Checker do not contract directly with individuals, the Individual caused LongSheng to enter into contracts with the Call Automation Vendor and the Checker on 17 March 2021 and 20 May 2021 respectively, to provide the services outlined at paragraph 3 above. The Individual used LongSheng as a corporate vehicle by which to procure the services of the Call Automation Vendor and the Checker. 5 Following the engagement of the Call Automation Vendor and the Checker, and pursuant to instructions from the Individual, the Call Automation Vendor provided 10 channels in its software, while the Checker subscribed for 10 telephone numbers in the name of LongSheng from which to make the automated marketing calls. 6 The Individual wished to test the systems provided by the Call Automation Vendor and the Checker, for which recipient telephone numbers were required. One of the Individual’s staff suggested to generate recipient telephone numbers by: (a) using commonly seen telephone numbers for the first 4 digits of each telephone number; and (b) randomly generating the last 4 digits of the telephone number by automated means. 7 The Individual authorised this method of generating the telephone numbers, and his staff proceeded to use Microsoft Excel to do so. 8 The Individual’s staff generated a total of 18,809 telephone number (“Subject Numbers”), which included 400 telephone numbers beginning with the digits “995”. “995” is the SCDF emergency line. 9 The Subject Numbers were contained in 3 lists, which were uploaded onto the Call Automation Vendor’s software by a member of the Individual’s staff. The Individual then clicked “send/call” in the Call Automation Vendor’s software to commence the automated marketing calls. 10 Between 25 and 28 June 2021, a total of 22,268 automated marketing calls were made (the “Subject Calls”), of which 433 were to the SCDF emergency line (the “Incident”). Such calls were not blocked as the SCDF emergency line was not registered in the DNCR. 11 On 28 June 2021, while reviewing the call recordings, the Individual discovered the calls made to the SCDF emergency line and immediately instructed his staff to stop using the Call Automation Vendor’s software. He also contacted the Call Automation Vendor to stop making further automated marketing calls; and deleted the lists containing the Subject Numbers. Findings and Basis for Determination The prohibition under Section 48B of the PDPA 12 Based on the circumstances of the Incident as set out above, the Commission’s investigation focused on whether the Individual had breached section 48B(1) of the PDPA by sending, causing to be sent, or authorising the sending of “applicable messages” - namely, (i) messages with a Singapore link to (ii) telephone numbers generated by a dictionary attack or address harvesting software (""Section 48B Prohibition""). 13 The Section 48B Prohibition and other provisions of the PDPA setting out relevant definitions are reproduced below: Term and definition (…) a person must not send, cause to be sent or PDPA provision s48B(1) authorise the sending of an applicable message. “applicable message” means a message with a s48A(1) Singapore link that is sent to any applicable telephone number; “message” means any message, whether in sound, text, s36(1) visual or other form; (2) In this Part, an applicable message has a Singapore link in any of the following circumstances: s48A(2) (a) the message originates in Singapore; (b) the sender of the message — (i) where the sender is an individual — is physically present in Singapore when the message is sent; or (ii) in any other case — (A) is formed or recognised under the law of Singapore; or (B) has an office or a place of business in Singapore; (c) the telephone, mobile telephone or other device that is used to access the message is located in Singapore; (d) the recipient of the message — (i) where the recipient is an individual — is physically present in Singapore when the message is accessed; or (ii) in any other case — carries on business or activities in Singapore when the message is accessed; (e) if the message cannot be delivered because the telephone number to which the message is sent has ceased to exist (assuming that the telephone number existed), it is reasonably likely that the message would have been accessed using a telephone, mobile telephone or other device located in Singapore. “applicable telephone number” means a telephone s48A(1) number that is generated or obtained through the use of — (a) a dictionary attack; or (b) address‑harvesting software; “dictionary attack” means the method by which the s48A(1) telephone number of a recipient is obtained using an automated means that generates possible telephone numbers by combining numbers into numerous permutations; “address‑harvesting software” means software that is s48A(1) specifically designed or marketed for use for — (a) searching the Internet for telephone numbers; and (b) collecting, compiling, capturing or otherwise harvesting those telephone numbers 14 The Section 48B Prohibition was introduced as part of the 2020 amendments to the PDPA and came into effect on 1 February 2021. It was intended to supplement the existing “Do Not Call” provisions in Part 9 of the PDPA in striking the correct balance between safeguarding consumer interest and permitting legitimate business interests in direct marketing by: (a) establishing clear guardrails for sending unsolicited commercial messages; 1 and (b) addressing consumer annoyance and deterring spammers who use technologies that make it easier to indiscriminately send unsolicited commercial messages (including robocalls) to a large number of recipients.2 15 The Section 48B Prohibition operates by targeting the indiscriminate manner by which recipient telephone numbers may be generated and targeted, usually by automated means. It does not serve as a blanket prohibition on the sending of unsolicited commercial messages, and leaves room for legitimate direct marketing. Whether the Individual had contravened the s48B Prohibition 16 For the Individual to have breached the Section 48B Prohibition, he must have: (a) sent, cause to be sent or authorized the sending of; (b) a message; (c) with a Singapore link; (d) to telephone numbers generated or obtained through use of: 17 (i) a dictionary attack; or (ii) address harvesting software. Based on the facts of the Incident as set out above, the elements for breach of the Section 48B Prohibition are made out: 1 Singapore Parliamentary Debates (2 November 2020) vol 95, at page 36 (S Iswaran, Minister for Communications and Information) 2 Public Consultation Paper issued by the Ministry of Communications and Information and the Personal Data Protection Commission dated 14 May 2020, at paragraphs 53 54(b) (a) The Individual specifically authorised and caused the making of the Subject Calls to the Subject Numbers. (b) The Subject Calls were automated calls based on a customised script provided by the Call Automation Vendor. The Subject Calls were therefore messages in sound form, and “messages” as defined by s36(1) of the PDPA. (c) The Subject Calls were made in Singapore. As such, the Subject Calls had a “Singapore link” within the meaning of s48A(2) of the PDPA. (d) The Subject Numbers were generated by using commonly seen telephone numbers for the first 4 digits, then randomising the remaining 4 digits. Strings of numbers were combined and resulted in the creation of 18,809 different permutations – i.e. unique telephone numbers – and the process was performed using automated means via Microsoft Excel. This was therefore a “dictionary attack” within the meaning of s48A(1) of the PDPA. 18 Accordingly, the Individual is determined to have contravened the Section 48B Prohibition. The Commission’s Decision 19 By using a “dictionary attack” to generate the Subject Numbers and then causing and/or authorising the Subject Calls to be made to the Subject Numbers, the Individual failed to stay within the “clear guardrails” of the PDPA to safeguard consumer interests. 20 To make matters worse, numerous calls were made to the SCDF emergency line. The importance of keeping the SCDF emergency line open and unobstructed for genuine emergencies cannot be over-emphasised. That said, the fact that automated marketing calls were made to the SCDF is not itself relevant to the Individual’s breach of the Section 48B Prohibition. The issue is with the method used to generate the Subject Numbers, and the Individual’s role in authorising the Subject Calls. 21 The Commission recognises that: (a) the Individual was cooperative with the Commission’s investigations; (b) the Individual has not previously contravened the PDPA; (c) the Individual had made efforts to ensure that he complied with his obligations under Part 9 of the PDPA relating to the DNCR when making the Subject Calls; and (d) the Individual voluntarily took action to cease the Subject Calls upon discovery that the SCDF had been called. 22 Having considered all the relevant factors in this case, the Commission hereby administers a warning to the Individual in respect of his breach of the Section 48B Prohibition. No other directions are necessary in view of the remedial actions already taken by the Individual. LEE TI-TING ASSISTANT COMMISSIONER FOR PERSONAL DATA PROTECTION ",Warning,065914363a4287df302d4869dbb9b671721521e1,"[""tags"",""decision"",""pdf-url"",""description"",""date"",""timestamp"",""url"",""title"",""nature"",""pdf-content""]" 2023-10-01T11:02:10+08:00,fbd32491db44d3d0c97aa12a99cefd61ec954264,11,11,1,1016,Sembcorp Marine was found not in breach of the PDPA in relation to an incident whereby threat actor(s) exfiltrated personal data by exploiting a zero-day vulnerability present in an application.,"[""Protection"", ""Not in Breach"", ""Others"", ""Ransomware"", ""No breach""]",2023-03-10,https://www.pdpc.gov.sg/-/media/Files/PDPC/PDF-Files/Commissions-Decisions/GD_Sembcorp-Marine-Ltd_070223.pdf,Protection,No breach of the PDPA by Sembcorp Marine,https://www.pdpc.gov.sg/all-commissions-decisions/2023/03/no-breach-of-the-pdpa-by-sembcorp-marine,2023-03-10,"PERSONAL DATA PROTECTION COMMISSION [2023] SGPDPCS 2 Case No. DP-2206-B9934 In the matter of an investigation under section 50(1) of the Personal Data Protection Act 2012 And Sembcorp Marine Ltd SUMMARY OF THE DECISION 1. On 25 July 2022, Sembcorp Marine Ltd (the “Organisation”) notified the Personal Data Protection Commission (the “Commission”) of a personal data breach that had occurred through the exploitation of the Log4J zero-day vulnerability (the “Incident”). 2. As a result of the Incident, the personal data of 25,925 individuals was exfiltrated. The personal data affected included their name, address, email address, NRIC number, telephone number, passport number, photograph, date of birth, bank account details, salary, and medical screening results. 1 3. The Organisation engaged an external cybersecurity company, Sygnia, to investigate the Incident. Its investigations found that the threat actor had exploited three Log4J vulnerabilities present in an application (the “Application”) to gain unauthorised access to a server as early as on 4 January 2022. The threat actor also deployed the “Cobalt Strike” beacon, conducted reconnaissance, and made lateral movements across several machines, before exfiltrating data between 10 and 23 June 2022, and deploying a ransomware on 28 June 2022. 4. Threat intelligence research revealed that the ransomware campaign which affected the Organisation began targeting users of the Application in January 2022. Given that reports of the Log4J vulnerability were first made in December 2021, it would have been difficult for the Organisation to detect and prevent the infiltration when it was one of the early targets, having been infiltrated as early as 4 January 2022. 5. After finding out about the Log4J vulnerability, the Organisation took prompt actions to identify instances of Log4J vulnerabilities across all the software application it was using. The Organisation started identifying instances of Log4J vulnerabilities across its systems on 14 December 2021. It applied the security patches immediately when they were made available by the respective software vendors. The Organisation also implemented workarounds recommended by the vendors, for systems which patches were not available or had not been released. Additional measures such as blocking incoming and outgoing Log4J traffic were also taken. 2 6. We are satisfied that the Organisation had made reasonable security arrangements to protect personal data in its possession and/or control in relation to the Incident. The Organisation had in fact adopted good practices in relation to its Information and Communications Technology (ICT) systems. This included a cybersecurity testing programme, regular vulnerability assessment and penetration testing, and cyber security monitoring. 7. In view of the above, the Deputy Commissioner for Personal Data Protection is satisfied that the Organisation had met its Protection Obligation under section 24 of the PDPA. No enforcement action therefore needs to be taken in relation to the Incident. The following provision(s) of the Personal Data Protection Act 2012 had been cited in the above summary: Protection of personal data 24. An organisation shall protect personal data in its possession or under its control by making reasonable security arrangements to prevent – (a) unauthorised access, collection, use, disclosure, copying, modification, disposal or similar risks; and (b) the loss of any storage medium or device on which personal data is stored. 3 ",Not in Breach,fa527b079427e2423cb0a716970088f54b497254,"[""tags"",""decision"",""pdf-url"",""description"",""date"",""timestamp"",""url"",""title"",""nature"",""pdf-content""]" 2023-10-01T11:02:10+08:00,fbd32491db44d3d0c97aa12a99cefd61ec954264,12,12,1,1016,"A financial penalty of $62,400 was imposed on Eatigo International for failing to put in place reasonable security arrangements to protect users' personal data in its possession or under its control.","[""Protection"", ""Financial Penalty"", ""Accommodation and F&B""]",2023-03-10,https://www.pdpc.gov.sg/-/media/Files/PDPC/PDF-Files/Commissions-Decisions/GD_Eatigo-International-Pte-Ltd_211222.pdf,Protection,Breach of the Protection Obligation by Eatigo International,https://www.pdpc.gov.sg/all-commissions-decisions/2023/03/breach-of-the-protection-obligation-by-eatigo-international,2023-03-10,"PERSONAL DATA PROTECTION COMMISSION [2022] SGPDPC 9 Case No. DP-2010-B7267 In the matter of an investigation under section 50(1) of the Personal Data Protection Act 2012 And Eatigo International Pte. Ltd. … Organisation DECISION Page 1 of 22 Eatigo International Pte. Ltd. Lew Chuen Hong, Commissioner — Case No. DP-2010-B7267 21 December 2022 Introduction 1. For an organisation to effectively safeguard the personal data in its possession or control, it must first know what its personal data assets are. The surest way to ensure such visibility is to maintain a comprehensive personal data asset inventory. This case is, amongst other things, a cautionary tale of the consequences of not maintaining a proper personal data asset inventory. 2. On 29 October 2020, the Personal Data Protection Commission (the “Commission”) was notified by a third party about a possible data leak by Eatigo International Pte. Ltd. (the “Organisation”). A cache of personal data that was suspected to be from the Organisation’s database was being offered for sale on an online forum (the “Incident”). Facts of the Case 3. The Organisation provides an online restaurant reservation platform which offers incentives such as discounts to its users. In its daily operations, it regularly collects and processes the personal data of its users in order to facilitate restaurant reservations and the provision of incentives. 4. After the Commission was notified of the Incident, it informed the Organisation on 30 October 2020 of an online forum purportedly selling the personal data from various ecommerce websites, including a database containing personal data that were suspected to have been obtained from the Organisation. Separately, the Organisation was also notified of the Incident Page 2 of 22 on the same day by a user and a Channel News Asia journalist. The Organisation proceeded to carry out investigations. 5. The Organisation’s investigations revealed that the personal data for sale on the online forum did not match any current databases in use by the Organisation at the time of the Incident, but matched the structure of a legacy database which contained user data as of late 2018, when the database was last updated (the “Affected Database”). The Affected Database was hosted on the infrastructure of a Cloud Service Provider located in Singapore, and was previously in use by the Organisation until 2018. Thereafter, the Organisation migrated to its current online platform, which entailed a complete redevelopment of data storage and infrastructure. Whilst the Organisation did not intend to continue to utilise the personal data contained in the Affected Database, it was nevertheless retained to support the migration of data to the new platform. After the migration, the Affected Database was not included in the Organisation’s Virtual Private Network (“VPN”) infrastructure. Unfortunately, as the Organisation transitioned to the current engineering team, knowledge of the Affected Database was lost. 6. The Organisation was unable to ascertain exactly when the threat actor gained unauthorised access to the Affected Database. However, since the Affected Database was last updated in late 2018, the Incident was likely to have occurred some time between 2018 and 2020 (when the Affected Database was put up for sale on an online forum). Investigations revealed the following: (a) At the time of the Incident, the Affected Database was accessible from the internet and accessible by anyone who had the requisite credentials; (b) None of the Organisation’s employees at the material time had knowledge of the Affected Database or possessed the credentials to access the Affected Database; Page 3 of 22 (c) The databases inside the Cloud Service Provider’s Relational Database Services (“RDS”) were intended to have randomly generated alphanumeric passwords of a minimum 13-character length. However, there had been no such password rotation rules implemented for the Affected Database; (d) There was no security review conducted on the protection provided to the personal data contained in the Affected Database; (e) There was no system in place to monitor the exfiltration of large volumes of data from the Affected Database; and (f) No personal data asset inventory or access logs were maintained, and the Organisation was unable to establish how or when the threat actor gained unauthorised access to the Affected Database. 7. The Affected Database held the personal data of approximately 2.76 million of the Organisation’s users. Because the Organisation had effectively lost track of a database of that size, network security and access control measures deployed by the Organisation were not applied to the Affected Database. 8. Consequently, the Affected Database was accessed and likely exfiltrated in the Incident and put up for sale on an online forum. A sample of 154 personal data sets were also posted on the online forum. The types of personal data affected (the “Dataset”) were as follows: (a) Name; (b) Email; (c) Telephone number; (d) Gender; (e) Passwords in MD5 Hash; and Page 4 of 22 (f) Facebook ID number and tokens of around 10 users, which can provide access to the Facebook accounts of users and their accounts with the Organisation’s online platform. 9. The personal data of a total of 154 of the Organisation’s users were displayed in the forum post, and appeared to have been randomly selected from the Affected Database. As of 13 November 2020, the post on the online forum no longer lists the Organisation’s personal data for sale. 10. Upon discovery of the Incident, the Organisation implemented, or has been in the process of implementing, the following remedial actions: (a) The Affected Database was securely backed-up and then deleted; (b) All databases were ensured to be accessible only inside VPN (i.e. no direct internet access); (c) All passwords to access databases were changed as of 30 October 2020; (d) Affected individuals were notified; (e) Security Settings on Systems Infrastructure were upgraded; (f) Different VPN for different categories of staff were created: (g) Access security for data storages and cloud services was improved, including increasing the password rotation and strengthening the password rules. (h) All personal data in all non-production was anonymised; (i) The logging and monitoring systems was reviewed to detect data access anomalies and trace access; (j) Access for external services used with the Organisation’s platform was reviewed; (k) Penetration Testing was conducted; (l) All staff were updated on policies relating to network security, and subject to Data protection and social engineering prevention training; Page 5 of 22 (m) All internal users in the Organisation’s cloud infrastructure and data storage were subject to review; (n) Access and error logging for all databases were added; (o) The entire infrastructure, including which servers are currently inside vs. outside demilitarized zone (DMZ), was subject to review; and (p) Accelerated implementation of recommendations of security audit completed by an external consultant in September 2020. Findings and Basis for Determination The Protection Obligation under section 24 of the PDPA 11. Based on the circumstances of the Incident as set out above, the Commission’s investigations centred on whether the Organisation had breached its obligation under section 24 of the Personal Data Protection Act 2012 (“PDPA”) to protect personal data in its possession or under its control by taking reasonable security steps or arrangements to prevent unauthorised access, collection, use, disclosure, copying, modification, disposal or similar risks (“the Protection Obligation”). 12. For the reasons set out below, it is determined that the Organisation failed to implement reasonable security arrangements to protect the Affected Database from the risk of unauthorised access. This includes a failure to ensure that the Affected Dataset was properly accounted for in the Organisation’s personal data asset inventory, and a failure to implement reasonable data protection processes. 13. In determining what constitutes reasonable security steps or arrangements, an organisation should have regard to the nature of the personal data in its possession and control, as well as the impact that the disclosure of the data might have on the affected persons. As Page 6 of 22 stated in the Commission’s Advisory on Key Concepts in the PDPA (the “Advisory”)1 at [17.2]: “There is no ‘one size fits all’ solution for organisations to comply with the Protection Obligation. Each organisation should consider adopting security arrangements that are reasonable and appropriate in the circumstances, for example, taking into consideration the nature of the personal data, the form in which the personal data has been collected (e.g. physical or electronic) and the possible impact to the individual concerned if an unauthorised person obtained, modified or disposed of the personal data. For example, in the employment context, it would be reasonable to expect a greater level of security for highly confidential employee appraisals as compared to more general information about the projects an employee has worked on.” 14. The Affected Database contained personal data relating to approximately 2.76 million individuals, encompassing personal data such as passwords, access IDs and Facebook tokens. Given the high volume of personal data contained in the Affected Database, it was incumbent on the Organisation to implement policies and practices to meet such security needs to discharge its obligation under the Protection Obligation. Lapses in managing of personal data asset inventory 15. For organisations with substantial personal data assets, the maintenance of an accurate and up-to-date personal data asset inventory is a pre-requisite for complying with the Protection Obligation. The personal data asset inventory should catalogue all personal data assets in the organisation’s possession or control, so as to ensure that such personal data is covered by the organisation’s security measures. Maintaining such an inventory ensures that the organisation 1 Advisory Guidelines on Key Concepts in the PDPA (Rev 1 February 2021) Page 7 of 22 retains the necessary institutional memory of the personal data assets that is or was previously under its possession or control even if there is turnover of staff. Any significant lapse in an organisation’s inventory management and maintenance would impair the organisation’s ability to know whether the data protection processes it implemented are sufficient to cover all its personal data assets. 16. This requirement to maintain a personal data asset inventory is not novel. As stated in Re Management Corporation Strata Title Plan No. 3400 [2020] SGPDPC 10 at [13]: “In addition, it is important for an organisation to be aware of and track its personal data assets. The creation and maintenance of a personal data asset register (i.e. a record identifying all personal data in the organisation’s possession or control) is a good practice that would assist organisations to comply with the Protection Obligation. An up-to-date personal data asset register provides the organisation with an accurate record of all the personal data in its possession or control, and enables the organisation to ensure its periodic security reviews covers the personal data assets. It also enables the organisation to more effectively review the implementation of its data protection policies, for example, the access control list setting out the employees who have access to the IT systems the personal data asset is stored in, whether the internal business owner of the personal data asset has reviewed it for data quality issues, and initiating the process for disposing personal data that have reached the end of its life cycle within the organisation.” (emphasis added) 17. Similarly, it was stated in Re Civil Service Club [2020] SGPDPC 15 at [15]: Page 8 of 22 “From the Appointed Day, the Organisation’s failure to take any reasonable steps to ensure sufficient obligations are imposed on the Vendor (when developing and troubleshooting the CMS, Membership Portal and Virtual Cards) to protect the Members Data was a breach of its obligations under section 24 of the PDPA. A period of about five years had elapsed since 2 July 2014 to 2 July 2019. The Organisation, as owner of the CMS, should have included it as part of its personal data asset inventory and ensured that its data protection policies covered personal data held in the CMS. Had this been done, the Organisation would have identified these gaps in the business requirements for the CMS, which would have set it down the path to rectifying these gaps through one or both of the options discussed in the preceding paragraph. The Organisation, as owner of the CMS, is responsible for identifying the omission and articulating its business requirements relating to the protection of personal data stored in the CMS. This would have led to action by the Vendor in recommending technical fixes to enhance the CMS. It is the failure to identify the omission and articulate business requirements, and for a not-trivial period of five years, that is the gravamen of the Organisation’s breach of the PDPA.” (emphasis added) 18. In this connection, the Commission’s Guide to Developing a Data Management Programme (the “Guide”) states that an organisation should establish a personal data asset inventory as part of Data Protection Impact Assessment (“DPIA”), and sets out the information that should be recorded by the organisation at pages 13 and 23: “By conducting a DPIA, an organisation would be in a better position to assess if the handling of personal data complies with the PDPA or data protection best practices, and to implement appropriate policy, technical or process measures. For more Page 9 of 22 information on the DPIA, please refer to the Guide to Data Protection Impact Assessments. As part of a DPIA, it is recommended to establish a data inventory (see Data Inventory Maps, Data Flow Diagrams and Other Registers on page 23) and classify the risk level of the data in the context that it is collected, used and disclosed throughout the data life cycle, from creation, distribution, storage, to disposal. This may be mapped onto a risk matrix for assessment and implementation of appropriate control for the identified risk levels. ... Data Inventory Maps, Data Flow Diagrams and Other Registers Known risks should be managed through a good understanding of the life cycle and flow of personal data in your organisation. This can be done through documenting the personal data handled using diagrams and charts such as data inventory maps or data flow diagrams, as illustrated in Annex C. The data inventory map and data flow diagram should also include information on the business purposes for collection, use and disclosure of personal data, the individuals and third parties who handle personal data under the organisation’s possession or control, as well as the classification of the data to manage user access. They should also deal with when and how the organisation should dispose of or anonymise the personal data for long-term archival. As good practice, it is important that employees and third parties access personal data on a need-to-know basis. Different sets of data may be accessed by different parties.” (emphasis added) Page 10 of 22 19. In the present case, the Organisation’s oversight in failing to maintain the Affected Database in its personal data asset inventory resulted in the omission to extend its extant security arrangements to the Affected Database. This resulted in the following: (a) The Organisation did not maintain proper records of the Affected Database and was unable to locate documentation related to user permission for the Affected Database. There was a dearth of records of the details of the data lifecycle of the personal data in the Affected Database from collection to disposal. (b) After the re-development and migration of the Organisation’s online platform, the Organisation did not conduct a proper handover of the Affected Database despite the turnover in staff. This led to the Organisation’s engineering team in 2020 having no knowledge of the existence of the Affected Database or its access credentials. (c) Since the Organisation lacked visibility of the Affected Database, it was omitted from the Organisation’s periodic security review. The Organisation thus did not have the opportunity to assess whether the Affected Database needed to be retained, or whether its security arrangements should be updated. During the Commission’s investigations, the Organisation indicated that the Affected Database should not have been retained following the successful migration of the Organisation’s online platform in 2018. It stands to reason that if the Organisation had covered the Affected Database in its periodic security reviews and assessed that it should be deleted, the Incident could have been prevented. (d) Since the Affected Database was effectively forgotten about, the Organisation also did not put in place any systems to monitor the exfiltration of data from the Affected Database, thus impeding its ability to react swiftly to mitigate the effects of the Incident. Page 11 of 22 20. The Organisation’s negligence in this regard left an internet-accessible database containing the personal data of approximately 2.76 million individuals (i.e. the Affected Database) outside its data protection architecture, creating a clear vulnerability that was exploited by threat actors. 21. The Organisation’s poor knowledge management often led to it providing inconsistent, extraneous and dilatory responses to the Commission’s notices to produce specified information and documents (“NTPs”) relating to the Organisation’s access models, causing the Commission to expend substantial time and resources to seek various rounds of clarifications with the Organisation. This includes, but is not limited to, the following responses to the Commission’s NTPs: (a) On 16 November 2020, the Organisation stated that the Affected Database was only accessible through VPN via certificates. After the Commission sought further clarifications, the Organisation stated on 14 December 2020 that it was in fact not included in the Organisation’s VPN structure; (b) On 16 November 2020, the Organisation stated that only 14 users had VPN access, but subsequently stated on 14 December 2020 that a total of 29 users with access without VPN; and (c) The Organisation also gave conflicting information about its password policies regarding the Affected Database. On 16 November 2020, it purported to have put in place a password policy for the Affected Database prior to the Incident. However, on 10 February 2021, it indicated that no specifically predefined password rules applied to the Affected Database. On 4 March 2021, after further clarifications were sought, the Organisation stated that it no longer had the username and password for the Affected Page 12 of 22 Database, and that nobody from its engineering team had any knowledge of the username and password. Other lapses in the Organisation’s data protection policies and processes 22. Besides failing to adequately maintain its personal data asset inventory, investigations also revealed other lapses and shortcomings in the Organisation’s data protection policies and processes. As referenced in paragraph 18, the Guide states that by establishing a personal data asset inventory as part of an organisation’s DPIA, it would be better positioned to assess if the handling of personal data complies with the PDPA or data protection best practices, and to implement appropriate policy, technical or process measures. In this regard, aside from its lapses in its management of its personal data asset inventory, the Organisation also did not implement some other basic data protection processes. 23. First, organisations that have a high volume of personal data within their possession and / or control should implement sufficiently robust processes to protect personal data through reasonable security monitoring. This ensures that organisations have sufficient situational awareness of its network security, enabling it to react timeously to data breaches. This step is embedded into the responsibilities of a data protection officer, as stated in the Advisory at [21.4]: “An organisation’s DPO plays an essential role in how the organisation meets its obligations under the PDPA. The responsibilities of the DPO often include working with senior management and the organisation’s business units to develop and implement appropriate data protection policies and practices for the organisation. In addition, the DPO would undertake a wide range of activities, which may include producing (or guiding the production of) a personal data inventory, conducting data protection impact assessments, monitoring and reporting data protection risks, Page 13 of 22 providing internal training on data protection compliance, engaging with stakeholders on data protection matters and generally acting as the primary internal expert on data protection.” (emphasis added) 24. Examples of such security monitoring measures are provided in the Commission’s Guide to Securing Personal Data in Electronic Medium at [4.1(j)] and [9.1] applicable at the material time2: “Conduct periodic checks for personal data stored in ICT systems. For personal data that is not required in any form anymore, securely dispose the data (refer to section 8). If there is a need to retain the data but not in identifiable form, e.g. for performing data analytics, consider anonymising the data. …. Computer networks allow communication between computers and devices that are connected to them. Internal corporate computer networks may be connected to external networks, such as the Internet. It is important for an organisation to ensure that its corporate computer networks are secure. Vulnerabilities in the network may allow cyber intrusion, which may lead to theft or unauthorised use of electronic personal data. Defences that may be used to improve the security of networks include: • Intrusion prevention systems (“IPS”) - a device or software application that monitors network or system activities and prevents malicious activities or policy violations; 2 The guide has been replaced by the Guide to Data Protection Practices for ICT Systems (updated 14 September 2021), which recommends similar security monitoring measures at pages 10 and 17. Page 14 of 22 • Intrusion detection systems (“IDS”) – a network security appliance that monitors network and system activities for malicious activities and may raise alerts upon detecting unusual activities; • Security devices that prevent the unauthorised transfer of data out from a computer or network; • Firewalls; and • Web proxies, anti-virus and anti-spyware software.” (emphasis added) 25. In this case, the high volume of personal data in the Affected Database necessitated a higher level of security awareness through robust security monitoring. However, the Organisation’s monitoring system extended only to performance and latency monitoring. The Organisation did not implement security monitoring for exfiltration of sizeable volumes of data based on pre-set limits. Given the considerable volume of personal data in the Organisation’s possession and / or control, including the personal data of the approximately 2.76 million individuals contained in the Affected Database, this is a reasonable security arrangement that the Organisation should have implemented. 26. Second, given the volume of personal data under the Organisation’s possession and / or control, the Organisation also should carry out periodic security audits which should include a reasonable vulnerability assessment of its IT infrastructure. This would entail the discovery and mapping of all parts of the Organisation’s network, including the Affected Database. If this had been carried out, it might have led to the re-discovery of the Affected Database, which would have allowed the Organisation to take the necessary steps to either improve the security of the Affected Database or delete it entirely. However, based on the Commission’s Page 15 of 22 investigations, the Organisation conducted no such security audits in relation to the Affected Database. The Commissioner’s Preliminary Decision 27. In determining whether any directions should be imposed on the Organisation under section 48I of the PDPA, and/or whether the Organisation should be required to pay a financial penalty under section 48J of the PDPA, the factors listed at section 48J(6) of the PDPA were considered, with particular emphasis on the following factors: Mitigating Factors (a) The Organisation had implemented the remedial measures set out in paragraph 10 swiftly to address the Incident. Aggravating Factors (b) The Organisation was grossly negligent in its failure to keep proper records or documentation of the Affected Database and to effect a proper handover to new employees vis-à-vis the Affected Database. Most egregiously, there was no institutional memory amongst the Organisation’s employees of the Affected Database by late 2020, or of the access credentials. (c) The Organisation had left the Affected Database exposed to a risk of unauthorised access and exfiltration for a protracted period of time, from October 2018 to late 2020. (d) As stated in paragraph [21], the Organisation’s dilatory responses to the Commission’s NTPs resulted in delays in the investigations. Page 16 of 22 28. Additionally, the Organisation also impeded the Commission’s investigations by responding in an uncooperative and evasive manner to the Commission’s NTPs: (a) The Organisation objected to the Commission’s request for information about the access models implemented for current production databases, giving the excuse that it might create “additional security risks”; and (b) Similarly, objecting to provide information regarding access to the Affected Database, citing the reason that this was against their policy and might create “additional security risks” even though the Affected Database had already been deleted on 3 November 2020. 29. Organisations that are uncooperative and that throw up objections will only prolong investigations. The Commission will not be deterred by such tactics. If, as is possible in this case, the Organisation did not have the information or needed more time to recover the information, honesty is the best policy. Hiding behind vague notions like “additional security risks” without providing details can and will be interpreted as cavalier and obstructive, and will be taken as an aggravating factor when the eventual outcome is determined. 30. Based on the foregoing, the Commission made a preliminary decision to impose a financial penalty on the Organisation for its breach of the Protection Obligation. Representations Made by the Organisation 31. The Organisation was notified of the preliminary decision by way of the Commission’s letter dated 26 November 2021 and was invited to make representations. On 10 December 2021, the Organisation made the following representations to the Commission urging the Commission to impose a warning in lieu of a financial penalty, or to reduce the financial penalty to be imposed: Page 17 of 22 (a) The Organisation had not intended to frustrate the Commission’s investigation. Instead, the Organisation’s internal investigations and responses to the Commission’s NTPs were hampered due to diminished corporate knowledge of the Affected Database at the material time and the impact of the COVID-19 pandemic on its management and operations. In support, the Organisation stated that: i. On July 2018, the Organisation’s former Chief Technology Officer (“CTO”) resigned, with the various back-end engineers that he recruited following suit. Consequently, the new CTO and team of back-end engineers lacked corporate memory and had no knowledge of the Affected Database; ii. The internal investigations on the Incident were hampered by turbulence in the Company's organisation during the Covid-19 pandemic, and despite the steps taken to maintain system documentation, the Affected Database was not uncovered; and iii. The conduct cited in [21] and [28] above stemmed from a misunderstanding of the Commission’s queries and the new CTO, being from a different cultural background, being reluctant to provide sensitive data to the Commission; (b) The contemplated financial penalty in the preliminary decision would be crushing on the Organisation and would likely lead to financial distress and the closure of its business. As the Organisation operates in the food and beverages industry, its business suffered during the COVID-19 pandemic and left it in a risky financial position from which is it has yet to recover from. Any financial penalty imposed would adversely affect the Organisation’s business, and deter any further investors or lenders from providing any further loans or investments to the Organisation; and Page 18 of 22 (c) The impact of the Incident was limited. The Organisation raised the following points in support: i. The Organisation did not collect NRIC numbers, birth dates and sensitive financial data such as credit card information. The login passwords that were collected were encrypted using MD5 Hash ; ii. As of 10 December 2021, the Company received less than 100 requests from users to delete their accounts following the Incident; and iii. The online forum post initially offering personal data from the Affected Database for sale appears to have been taken down as of 13 November 2020. Diminished corporate knowledge and conduct during the Commission’s investigations 32. The Organisation’s representations in [31(a)] do not merit a waiver or reduction in the financial penalty imposed. Staff turnover is no excuse for a lack of corporate knowledge, and it is incumbent on organisations to take reasonable steps to bolster institutional memory to manage any security risks arising thereof. This includes the implementation of practices such as the maintenance of a personal data asset inventory as detailed in [16] to [18], which would have enabled it to conduct proper handovers to new staff. 33. As for the difficulties experienced by the Organisation during its own internal investigations and any misunderstandings it may have had in relation to the Commission’s NTPs, it should have been candid with the Commission about its difficulties and sought clarifications and extensions of time to respond to the NTPs. Instead, its lack of transparency during the investigation stage caused the Commission to expend substantial time and resources in engaging the Organisation. In its representations, the Organisation has also admitted that it Page 19 of 22 should have substantiated its position during the NTP stage to avoid giving the Commission the impression that it was being uncooperative and evasive. Likely impact of a financial penalty on the Organisation 34. One of the considerations in the imposition of a financial penalty is the likely impact of the imposition of such penalty on an organisation, including the ability of the organisation to continue its usual activities: see section 48J(6)(i). When determining the appropriate financial penalty, the Commission has consistently considered the financial circumstances of the organisation or person involved, bearing in mind that financial penalties imposed should avoid imposing a crushing burden or cause undue hardship on the organisation or person3. 35. After careful consideration, the Commission accepts the Organisation’s representation at [31(b)] that the imposition of the financial penalty proposed would likely lead to financial distress and the closure of its business. However, a mere warning is inappropriate in view of the egregiousness of the Organisation’s breach of the PDPA and the impact of the Incident. Hence, the imposition of a reduced financial penalty, to be paid out in instalments, would be more proportionate and appropriate in ensuring the Organisation’s compliance with the PDPA. 36. In arriving at its decision, the Commission had regard for the following factors concerning the Organisation’s financial situation, and the likely impact that the proposed financial penalty in the preliminary decision would have on it: (a) In the Organisation’s audited financial statements for the financial year ending 31 December 2020, its independent auditor stated that there was significant doubt on 3 Re Jigyasa [2021] SGPDPCR 1; Commeasure Pte Ltd [2021] SGPDPC 11; and Neo Yong Xiang (trading as Yoshi Mobile) [2021 SGPDPC 12 Page 20 of 22 the ability of the Organisation to continue as a going concern and to realise its assets and discharge its liabilities in the ordinary course of business; (b) The Organisation’s monthly income statements from 2021 indicated that it was incurring heavy net losses on a month-to-month basis (with the exception of one month); and (c) 37. The Organisation had various substantial short-term loans due in the near future. The above evinces a clear picture of an organisation in a parlous financial situation caused by the COVID-19 pandemic, with various debts and liability (some incurred to keep the business afloat) coming due in the near future. In view of this situation, the Commission shall refrain from imposing a financial penalty that might push the Organisation’s business even closer to the brink. Impact of the Incident 38. The Commission had already taken into account the impact of the Incident when calibrating the financial penalty in the preliminary decision. At the same time, the Commission also took into consideration the fact that the Affected Database contained the personal data of a very high number (2.76 million) of individuals, which necessitated the implementation of more robust security measures by the Organisation. The impact of the Incident should not be minimised, and the financial penalty imposed should reflect this. Acceptance of the Commission’s findings 39. Additionally, the Commission notes that the Organisation voluntarily accepted the Commission’s findings in the preliminary decision that it had failed to comply with the Protection Obligation and explicitly indicated that it would not seek to challenge these findings. Page 21 of 22 The Organisation’s voluntary acceptance of liability (even at this late stage) ought to be reflected in the financial penalty. Had the Organisation accepted responsibility for the Incident at an earlier stage of the investigation, it could have significantly shortened the time for investigations and resolution of this case through the expedited breach procedure and also benefited from greater mitigatory considerations. Nonetheless, an organisation that voluntarily accepts responsibility for its non-compliance with the PDPA should be recognised as an organisation that demonstrates its commitment to the Accountability Obligation and shows that it can be responsible for the personal data in its possession or under its control4: see [46] of Farrer Park Hospital Pte Ltd [2022] SGPDPC 6. 40. Having considered all the relevant factors in this case including the representations made by the Organisation, the Commission hereby requires the Organisation to pay a financial penalty of $62,400 in 12 monthly instalments by the due dates as set out in the notice accompanying this decision, failing which interest at the rate specified in the Rules of Court in respect of judgment debts shall accrue and be payable on the outstanding amount of such financial penalty until the financial penalty is paid in full. 41. In view of the remedial actions already been taken by the Organisation, no further directions need be issued to the Organisation YEONG ZEE KIN DEPUTY COMMISSIONER FOR COMMISSIONER FOR PERSONAL DATA PROTECTION 4 Refer to section 11(2) of the PDPA. Page 22 of 22 ",Financial Penalty,d2f8ccda43f78a0b1e149fae38950a4570f436dc,"[""tags"",""decision"",""pdf-url"",""description"",""date"",""timestamp"",""url"",""title"",""nature"",""pdf-content""]" 2023-10-01T11:02:10+08:00,fbd32491db44d3d0c97aa12a99cefd61ec954264,13,13,1,1016,Directions were issued to CPR Vision Management Pte Ltd to conduct a security audit of its technical and administrative arrangements for the protection of personal data in its possession or control and rectify any security gaps identified in the audit report. This is pursuant to a data breach incident where CPR Vision Management Pte Ltd’s server and network storage devices were subjected to a ransomware attack.,"[""Protection"", ""Directions"", ""Others"", ""Ransomware"", ""Data Intermediary"", ""Retention""]",2023-02-10,https://www.pdpc.gov.sg/-/media/Files/PDPC/PDF-Files/Commissions-Decisions/Decision---CPR-Vision-Management-Pte-Ltd---071222.pdf,Protection,Breach of the Protection Obligation by CPR Vision Management Pte Ltd,https://www.pdpc.gov.sg/all-commissions-decisions/2023/02/breach-of-the-protection-obligation-by-cpr-vision-management-pte-ltd,2023-02-10,"PERSONAL DATA PROTECTION COMMISSION [2022] SGPDPCS 17 Case No. DP-2207-B8974 In the matter of an investigation under section 50(1) of the Personal Data Protection Act 2012 And CPR Vision Management Pte Ltd L’Oreal Singapore Pte Ltd L’Occitane Singapore SUMMARY OF THE DECISION 1. The Personal Data Protection Commission (the “Commission”) received data breach notification reports from (i) L’Oreal Singapore Pte Ltd (“L’Oreal”) on 29 October 2021 and (ii) L’Occitane Singapore Pte Ltd (“L’Occitane”) on 1 November 2021 respectively of a ransomware attack on their customer relationship management (“CRM”) system vendor, CPR Vision Management Pte Ltd (the “Organisation”). The Organisation is a data intermediary that helped to process personal data collected by L’Oreal and L’Occitane. 2. The ransomware attack affected a server and three network attached storage (“NAS”) devices in the Organisation’s office (“office network”), and led to the Page 1 of 6 encryption of the personal data belonging to 83,640 L’Occitane’s customers and 35,079 L’Oreal’s customers, which included their name, address, email address, mobile number, NRIC number, date of birth, age, gender, race, nationality, loyalty points and amount spent. 3. The Organisation requested, and the Commission agreed, for this matter to proceed under the Expedited Decision Breach Procedure. To this end, the Organisation voluntarily and unequivocally admitted to the facts set out in this decision. It also admitted to a breach of the Protection Obligation under Section 24 and the Retention Limitation Obligation under Section 25 of the Personal Data Protection Act (the “PDPA”). 4. The Organisation’s internal investigations found the threat actor had first gained access to the office network via a compromised user account VPN connection on 13 October 2021 before executing the ransomware attack on or about 15 October 2021. However, due to the limited data logs available on the Organisation’s FortiGate firewall and VPN appliance, the Organisation was not able to determine how the threat actor gained access to the compromised user account VPN. As part of the immediate remediation efforts, the Organisation reset the credentials of the compromised user account VPN and the password credentials of all VPN accounts across the Organisation. Page 2 of 6 5. The Organisation admitted that its endpoint security solution would have been able to detect and block the unauthorised entry attempts to the office network affected in the Incident. However, the Organisation failed to extend the deployment of this protection solution to the affected office network. This could have been because the domain controller server within the affected office network had been earmarked to be decommissioned after the data was copied to MS365 Sharepoint. Another reason for the omission may have been the fact that the Organisation set up the affected office network for business continuity purposes, when it shifted to its new premises, sometime between 6 – 9 April 2020, on the eve of the nation-wide COVID-19 circuit breaker in Singapore. 6. The Commission finds the Organisation in breach of the Protection Obligation as it failed to have reasonable security arrangements in place to protect the personal data in its possession and control. As a CRM system vendor, the Organisation processes and processed a high volume of web traffic containing personal data on behalf of many e-commerce retailers, including L’Oreal and L’Occitane, and would ordinarily be held to a higher standard. The Organisation’s omission to deploy its endpoint security solution to the affected office network suggests that the Organisation failed to maintain an inventory of its data assets. 7. Even if there were extenuating circumstances in April 2020 which could have partly excused the Organisation’s omission to include the affected office network in its data inventory, it was inexcusable for the Organisation to let this state of affairs Page 3 of 6 persist for more than one and-a-half years, from April 2020 until October 2021. We should add however, that as part of its remediation efforts, the Organisation has since ensured that its endpoint security solution was deployed to all office and enduser devices. 8. The Organisation also admitted to being in breach of the Retention Limitation Obligation. The Organisation admitted that the affected personal data in the Incident had been legacy content, which should have been deleted together with the domain controller server earmarked for decommissioning, and for which no business or legal purpose existed for retention. The Organisation highlighted however, that this lapse was not in accordance with its own data retention policy. Had the Organisation complied with the Retention Limitation Obligation and deleted the personal data in question, the Incident would not have amounted to a breach of the Retention Limitation Obligation under the PDPA. 9. In the course of our investigations, L’Oreal furnished documentary evidence which showed that L’Oreal had specifically instructed the Organisation, pursuant to its data retention policies, to delete the affected personal data on 26 March 2021. This was duly acknowledged by the Organisation, and the Organisation furnished a purported Certificate of Destruction dated 17 May 2021 stating that the personal data had been deleted on 6 May 2021. Page 4 of 6 10. Similarly, L’Occitane also raised its concerns that the Organisation failed to seek its prior written consent before duplicating the personal data to other nonproduction environments. 11. The Commission is satisfied that neither L’Oreal nor L’Occitane had any knowledge of the retention and storage of the legacy personal data by the Organisation on the affected NAS device; and neither had any control over the NAS device used by the Organisation to store the personal data affected by the ransomware attack. Both L’Oreal and L’Occitane had also adequately provided in their contracts with the Organisation to ensure compliance with the Protection and Retention Limitation Obligations under the PDPA. The Commission is therefore of the view that despite the personal data breach incident, L’Oreal and L’Occitane had acted consistently with and complied with the relevant obligations under the PDPA. 12. Having considered the circumstances set out above, including the Organisation’s upfront admission of liability, and the fact that data analysis conducted by the data security team of the Organisation’s parent company did not uncover any evidence to suggest that data exfiltration or modification had occurred, the Commission considered that it would be most appropriate in lieu of imposing a financial penalty, to direct the Organisation to comply with the following action: a. Conduct a thorough security audit (with report) of its technical and administrative arrangements for the protection of personal data in its possession or control; b. Rectify any security gaps identified in the security audit report; Page 5 of 6 c. Conduct a comprehensive review of all of the Organisation’s databases containing personal data to ensure full compliance with the Retention Limitation Obligation under Section 25 PDPA; d. Review and update the personal data policies of the Organisation as applicable, including clarification of the roles of data intermediaries and vendors in complying with the Retention Limitation Obligation under section 25 of the PDPA, within 60 days from the date the security audit report is delivered to the Organisation; and e. Inform the Commission within 1 week of the completion of the steps directed above. The following are the provision of the Personal Data Protection Act 2012 cited in the above summary: Protection of personal data 24. An organisation must protect personal data in its possession or under its control by making reasonable security arrangements to prevent – (a) unauthorised access, collection, use, disclosure, copying, modification or disposal or similar risks and; (b) the loss of any storage medium or device on which personal data is stored. Retention of personal data 25. An organisation must cease to retain its documents containing persona 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 being served by retention of the personal data; and (b) retention is no longer necessary for legal or business purposes. Page 6 of 6 ",Directions,7e9168136ea5e122bc3f4577c70535e0fc6c7689,"[""tags"",""decision"",""pdf-url"",""description"",""date"",""timestamp"",""url"",""title"",""nature"",""pdf-content""]" 2023-10-01T11:02:10+08:00,fbd32491db44d3d0c97aa12a99cefd61ec954264,14,14,1,1016,"RedMart had failed to obtain consent and inform its suppliers of the purpose for collecting images of the physical NRICs and other identification documents. However, the Commission had subsequently assessed that RedMart had met the requirements for reliance on the Legitimate Interests Exception and complied with the proposed direction. As such, no direction was issued to RedMart.","[""Consent"", ""Notification"", ""Purpose Limitation"", ""No Further Action"", ""Wholesale and Retail Trade""]",2023-02-10,https://www.pdpc.gov.sg/-/media/Files/PDPC/PDF-Files/Commissions-Decisions/Decision---RedMart-Limited---18012023.pdf,"Consent, Notification, Purpose Limitation","Breach of the Consent, Notification and Purpose Limitation Obligations by RedMart","https://www.pdpc.gov.sg/all-commissions-decisions/2023/02/breach-of-the-consent,-notification-and-purpose-limitation-obligations-by-redmart",2023-02-10,"PERSONAL DATA PROTECTION COMMISSION Case No. DP-2105-B8405 In the matter of an investigation under section 50(1) of the Personal Data Protection Act 2012 And RedMart Limited … Organisation DECISION Page 1 of 11 RedMart Limited [2023] SGPDPC 1 Yeong Zee Kin, Deputy Commissioner — Case No. DP-2105-B8405 18 January 2023 Introduction 1 On 31 May 2021, the Personal Data Protection Commission (the “Commission”) received a complaint that RedMart Limited (the “Organisation”) was collecting images of the physical NRICs and other identification documents of suppliers making deliveries to its warehouses (the “Incident”), and that this practice did not appear to be in compliance with the Personal Data Protection Act 2012 (“PDPA”). Facts of the Case 2 Investigations revealed that the Organisation operated two warehouses at 47 Jalan Buroh, CWT Distripark, Singapore 619491 (“Warehouses”) which were used to store goods and produce sold by the Organisation. The Warehouses were regularly visited by suppliers delivering goods and produce (“Visitors”), and the Organisation implemented measures to regulate such Visitors’ access to the Warehouses. Security checkpoints at the Warehouses used an Organisation-issued tablet computer Page 2 of 11 (“Tablet”) to take photographs of Visitors’ NRIC or other identification documents (“ID Photographs”). The Organisation said it collected ID Photographs to Visitors seeking access to areas where food safety risks had to be managed. The Organisation explained that these measures are intended to deter acts that could compromise food safety and facilitate investigations of food safety incidents. 3 Prior to the Incident, there were no notices at the Warehouses’ security checkpoints informing Visitors of the purpose for collection of ID Photographs. After being notified by the Commission of the Incident, the Organisation put up notices at the Warehouses’ security checkpoints to inform Visitors of the purpose of collection of ID Photographs. Findings and Basis for Determination 4 Considering that the Tablets remained in the possession of the Organisation’s security team at all times, and that there was no evidence of misuse of the ID Photographs collected, the impact of the Incident was limited. Having collected the ID Photographs, the Organisation is obliged to protect these and associated personal data to a standard commensurate to the risks that unauthorised access, use or disclosure might pose to respective individuals. The nub of the issue in this case is the legal basis upon which these ID Photographs were collected. The Organisation could have relied on two possible grounds. Page 3 of 11 5 First, Visitors may have volunteered their IDs to be photographed on request. However, the Organisation’s failure to inform Visitors of the purpose for collecting the ID Photographs was contrary to sections 14(1)(a) and 18(b) of the PDPA read with section 20. Further, the collection of a photographic image of their IDs was a condition for entry. Visitors enter the Warehouses to make deliveries as part of their employment or business. It is not a product or service that they chose to access, as contemplated by section 14(2)(a) of the PDPA. Hence, even if the requirement of notification of purpose had been met, this is not a situation where persons making deliveries as part of their employment or business could be said to have consented to allowing a photographic image of the IDs to be taken as a condition for a product or service provided by the Organisation which such persons wanted access to. Consent is not the most appropriate basis for collection and use of the ID Photographs. Accordingly, the Organisation did not obtain valid consent from the Visitors for collecting the ID Photographs, and would have breached section 13 of the PDPA if this ground was relied on. 6 There was an alternate ground available to the Organisation. The purpose of public food hygiene and safety, cited by the Organisation in the present case, is a legitimate interest of the Organisation, and also of its business partners and ultimately, consumers. Ensuring good public hygiene and safety benefits all downstream food and beverage businesses, supermarkets and diners who eventually consume food that was stored in the Warehouses. The Organisation may therefore rely on the exception at Paragraph 1, Part 3 of the First Schedule of the PDPA (“Legitimate Page 4 of 11 Interests Exception”) to collect the ID Photographs without Visitors’ consent. The Legitimate Interests Exception was introduced in the PDPA effective 1 February 2021, and could have been invoked by the Organisation any time after this date. 7 To rely on the Legitimate Interests Exception, prior to collecting the ID Photographs, the Organisation would have had to conduct and document an assessment determining whether the Organisation’s interests in collecting the ID Photographs outweighed the adverse effect to Visitors. For any adverse effects identified, the Organisation would have had to implement reasonable measures to eliminate, mitigate or reduce the likelihood of occurrence. The Organisation would also have had to provide Visitors with reasonable access to information about the Organisation’s collection of the ID Photographs, which could have been done by way of disclosure in the Organisation’s public data protection policy. 8 The Commission accepts that the Organisation implemented access controls to regulate how the ID Photographs were collected and stored, which in turn reduced the risk of misuse of the ID Photographs. Notwithstanding, based on the reasons provided by the Organisation, the collection had been solely or primarily to deter acts that could compromise food safety and facilitate investigations into food safety incidents. The collected ID Photographs contained full NRIC / ID numbers together with other personal information that, in combination, had identified Visitors to a high degree of fidelity. The Commission noted that the collection of ID Photographs or full NRIC numbers had not been required by law in this case, and it is incumbent on the Page 5 of 11 Organisation to justify why the collection of ID Photographs had been a reasonable practice in these circumstances. The Commission’s Preliminary Decision 9 In view of the above, bearing in mind that the Organisation had taken some steps to remediate the Incident, the Commission’s preliminary decision was to give the following directions to the Organisation: (a) To within 60 days of this decision, conduct and document an assessment to: (i) evaluate whether the collection of ID Photographs from Visitors is reasonably necessary for the Organisation’s interests in deterring and investigating security incidents at the Warehouses. (ii) If the Organisation intends to rely on the Legitimate Interests Exception for such collection, to: (A) identify whether the Organisation’s collection of ID Photographs (or other personal data) from Visitors is likely to have an adverse effect on Visitors; (B) identify reasonable measures that could be implemented to eliminate, mitigate, or reduce the likelihood of such adverse effects occurring; and Page 6 of 11 (C) determine whether the Organisation’s interest in collecting the ID Photographs (or other personal data) outweighs the adverse effect to Visitors (if any) after the above measures are implemented. (iii) If the Organisation does not intend to rely on the Legitimate Interests Exception, to identify the basis under which the Organisation intends to collect the ID Photos (or other personal data) from Visitors, and to implement the necessary policies and processes for such collection to be in compliance with the PDPA. (b) To provide the Commission with a copy of the Organisation’s above assessment within 14 days of its completion. The Organisation’s Representations 10 The Commission’s preliminary decision was communicated to the Organisation on 8 July 2022. On 22 July 2022, the Commission received representations from the Organisation in respect of the preliminary decision. The Organisation claimed that it had complied with the PDPA when collecting ID Photographs from Visitors, on the following bases: (a) It was in the national interest to collect ID Photographs in order to establish the identities of Visitors to a high fidelity and deter potential food security incidents Page 7 of 11 at the Warehouses, an exception to the obligation to obtain consent pursuant to Paragraph 2, Part 2 of First Schedule to the PDPA (“National Interest Exception”); (b) The collection of ID Photographs was necessary to facilitate investigations into food security incidents at the Warehouses, an exception to the obligation to obtain consent pursuant to Paragraph 3, Part 3 of First Schedule to the PDPA (“Investigations Exception”); and/or (c) There was deemed consent from Visitors for collection of the ID Photographs, as these were volunteered, and collected for the reasonable purposes as part of efforts to ensure food security (pursuant to section 15 of the PDPA). 11 The Organisation’s representations are not accepted: (a) The National Interest Exception does not apply. The Organisation’s food security concerns, while valid, are limited to its own Warehouses and are not at the level of the “national defence or “national security” concerns contemplated by the definition of “national interest” at section 2 of the PDPA. (b) The Investigations Exception does not apply. In order to rely on the Investigations Exception, the collection of personal data must be for the purpose of an ongoing investigation and cannot be for a hypothetical future investigation. (c) There was no deemed consent from Visitors for the Organisation’s collection of the ID Photographs. Visitors were not given a choice in the matter and cannot be said to have voluntarily provided their IDs as contemplated under section 15(1) Page 8 of 11 of the PDPA. Further, it would not have been obvious to Visitors that fact that photographic images of IDs would be taken and then stored. 12 Insofar as collection and use of ID Photographs from Visitors prior to 8 July 2022 had been on the bases cited by the Organisation above, the Commission finds that the Organisation had not been in compliance with the PDPA. Reliance on Legitimate Interests Exception 13 However, the Organisation also informed the Commission of its intention to rely on the Legitimate Interests Exception as the basis for such collection going forward. Together with its representations, the Organisation provided the Commission with a copy of an internal assessment it had carried out on 22 July 2022 for its reliance on the Legitimate Interests Exception going forward (“LIE Assessment”). 14 In the LIE Assessment, the Organisation identified that there was a need to establish and/or verify the identities of Visitors to the Warehouses to a high degree of fidelity, when they were entering areas of the Warehouses containing dry food and fresh produce that were susceptible to contamination and tampering. Collection of ID Photographs served the legitimate interests of deterring and investigating potential food security incidents, which could cause harm to the public and damage to the Organisation’s reputation. Page 9 of 11 15 The Organisation identified that its collection of the ID Photographs exposed Visitors to the risks of unauthorised use and disclosure of their personal data, and detailed the measures it had implemented to eliminate or mitigate these adverse effects. These included: (a) limiting collection of ID Photographs to only Visitors accessing areas of the Warehouses with higher risk of food security incidents; (b) restricting access to the Tablets; (c) restricting the application used to collect ID Photographs on the Tablets to only work when connected to a dedicated Wi-Fi network at the Warehouses; (d) immediately uploading the collected ID Photographs to the Organisation’s backend server (and not storing them locally on the Tablets); (e) limiting access to the ID Photographs (on the backend server) to the Organisation’s DevOps team, and only when such access was on-site at the Organisation’s offices and connected to its internal network; and (f) retaining the ID Photographs for a maximum of one year. 16 The Organisation assessed the benefit in collecting the ID Photographs to be “significant” considering the potential harm that could be caused to the public by a food contamination incident. The Organisation also assessed that its implementation of the above measures rendered the “adverse impact from users” to be “low”. The Organisation confirmed that it would notify Visitors of its reliance on the Legitimate Interests Exception by way of notices posted at the relevant security posts. Page 10 of 11 17 The Commission accepts that the Organisation’s interest in deterring food security incidents at the Warehouses is legitimate. The Commission also accepts that there may be a legitimate interest served in implementing enhanced identification requirements to regulate access to high risk areas, and that the collection of ID Photographs promote this interest. Most importantly, the Commission recognises that the risks of unauthorised access, use and/or disclosure of the ID Photographs have been significantly lowered on account of the enhanced access controls implemented by the Organisation to protect the ID Photographs. The Commission’s Decision 18 For the above reasons, the Commission is satisfied that the Organisation has met the requirements for reliance on the Legitimate Interests Exception in this case. As the Organisation has already complied with the proposed direction (contemplated at [9] above) by carrying out the LIE Assessment to the Commission’s satisfaction, it is no longer necessary for the direction to be issued. YEONG ZEE KIN DEPUTY COMMISSIONER FOR PERSONAL DATA PROTECTION Page 11 of 11 ",No further action,4eaff99c5b7557a88a0ca128e03e4b18ea52c953,"[""tags"",""decision"",""pdf-url"",""description"",""date"",""timestamp"",""url"",""title"",""nature"",""pdf-content""]" 2023-10-01T11:02:10+08:00,fbd32491db44d3d0c97aa12a99cefd61ec954264,15,15,1,1016,"Directions were issued to Thomson Medical to conduct scan of the web to ensure no publication of affected personal data online and to include in the review of its application deployment process, measures such as the arrangements for security testing and the implementation of data retention policy. This is pursuant to a data breach incident from an unsecured Health Declaration Portal which enabled public access to visitors' personal data.","[""Protection"", ""Directions"", ""Healthcare""]",2022-12-19,https://www.pdpc.gov.sg/-/media/Files/PDPC/PDF-Files/Commissions-Decisions/Decision---Thomson-Medical-Pte-Ltd---140922.pdf,Protection,Breach of the Protection Obligation by Thomson Medical,https://www.pdpc.gov.sg/all-commissions-decisions/2022/11/breach-of-the-protection-obligation-by-thomson-medical,2022-12-19,"PERSONAL DATA PROTECTION COMMISSION [2022] SGPDPCS 15 Case No. DP-2010-B7246 In the matter of an investigation under section 50(1) of the Personal Data Protection Act 2012 And Thomson Medical Pte. Ltd. SUMMARY OF THE DECISION 1. On 26 October 2020, the Personal Data Protection Commission (the “Commission”) was notified that the Thomson Medical Pte. Ltd. (the “Organisation”) Health Declaration Portal was not secure, enabling public access to the personal data of visitors (the “Incident”) stored in a CSV (comma separated values) file. 2. Visitor data collected on the Organisation’s Health Declaration Portal had been stored concurrently in a publicly-accessible CSV file as well as a secured 1 database from 16 April 2020, when the health declaration portal was first used by the Organisation to 8 September 2020, when the storage of the visitor data was changed to only the secured database instead of the CSV file. The CSV file was hosted on the Organisation’s web server. 3. The Organisation admitted that, contrary to the instructions given to the employee to switch the data storage from the CSV file to secured database exclusively, and the organisation’s protocols, its in-house developer had omitted to remove a software code, causing the visitor data to be stored in the CSV file and the same in-house developer had omitted to change the default web server configuration, thereby allowing public access to the hosted CSV file. The switch to storage in a secured database would have ensured access controls by requiring user login ID and secure password protection, as well as encryption of data transfers using SSL certificates. The access controls would ensure that only authorized users would be able to access the data. 4. The Commission’s investigations revealed that the affected CSV file contained the personal data of 44,679 of the Organisation’s visitors, including the date and time of visit, temperature, type of visitor (purpose of visit), name of visitor, name of newborn, contact number, NRIC/FIN/passport number, doctor/clinic name or room visiting, and answers to a health declaration questionnaire (which included a declaration by the visitor that he/she did not have any symptoms or recent exposure to the Covid-19 virus). 2 5. The Organisation accepted that it was in breach of the Protection Obligation under section 24 of the Personal Data Protection Act (“PDPA”). The Commission finds that the Organisation had breached section 24 of the PDPA for two reasons. 6. First, even though the Organisation’s existing policies required the visitor data collected to be stored in a secured database, the Organisation failed to ensure that there were processes in place to ensure these policies and instructions would be complied with. The Organisation stated that the in-house developer had been the only staff in its IT department familiar with the programming language used for the health declaration form. This, however, should not have prevented the Organisation, as an example, from requiring the in-house developer to demonstrate to another staff member, and for that staff member to verify that the storage instructions had been complied with. As noted in Re Aviva Ltd [2017] SPDPC 14, relying solely on individual employees to perform their tasks diligently, with no oversight or supervision, is not a reasonable security arrangement. 7. Second, the Organisation failed to conduct reasonable pre-launch testing before the Health Declaration Portal went live. While acceptance testing and some technical tests were conducted, there had been no security testing to verify that there were access controls to the visitor data collected. 3 8. Having said that, it is a mitigating fact that the Organisation’s in-house developer sought to comply with the Organisation’s policies and swiftly rectified the software code on 8 September 2020, when he first discovered the coding error whilst updating the health declaration questionnaire. 9. The forensic investigator engaged by the Organisation did not uncover any evidence that the disclosed data had been exported and posted online, including on the Dark Web. The Organisation’s server logs also revealed that the CSV file was only accessed 4 times from 3 different local IP addresses. Given the timing of the access instances, it is probable that these instances were made by the complainant and by the Commission when investigating this matter, which suggests that the impact of this Incident was limited. 10. The Commission noted a parallel between the facts of this case and Re Spear Security Force Pte. Ltd. [2016] SGPDPC 12, in that both cases arose from a single complaint about a potential breach of the PDPA, with no other evidence suggesting that the personal data had actually been exposed to unauthorised third parties due to the lapses by the Organisation. 11. The personal data exposed here included the clinic or room that the individual intended to visit, and the reason for the visit. This could be to seek treatment, accompany a patient, or a business visit made by a sales representative of a pharmaceutical or medical device company. While the personal data exposed 4 included some health-related information, this had essentially been health declaration information for the purpose of containment of the pandemic. The information did not in fact reveal any potentially sensitive information such as whether the visitor was Covid-19 positive.1 12. The personal data disclosed is also not on par with Re Singapore Health Services Pte. Ltd.& Ors. [2019] SGPDPC 3 (“Singhealth”). In the Singhealth case, we recognised the sensitivity involved in the exposure of the affected individuals’ personal data in their “clinical episode information, clinical documentation, patient diagnosis and health issues and Dispensed Medication Records” as the information and personal data affected may allow one to deduce the condition for which a patient had sought treatment, and may lead to the unintended disclosure of serious or socially embarrassing illnesses.2 While there is some personal data in the present case which may reveal the clinic which an affected individual had sought treatment, this is of a much more limited scope as compared to the Singhealth case. 13. The Commission accepted that the Organisation took prompt remedial action to contain the exposure. This include removing the affected CSV file and changing all the passwords to the database, even though it was not affected by the Incident. To prevent a recurrence of a similar incident, the Organisation also 1 Cf Re Terra Systems Pte Ltd [2021] SGPDPC 7. 2 See Re Singapore Health Services Pte. Ltd.& Ors. [2019] SGPDPC 3, at [139]. 5 reviewed its application deployment process to take into consideration data security, and rectified all potential gaps discovered during a vulnerability scan. 14. Given the lack of evidence suggesting that personal data had actually been exposed to unauthorised third parties due to the lapses by the Organisation and the limited impact of the Incident, the Commission considered that it would be most appropriate in lieu of imposing a financial penalty, to impose directions. 15. Another factor which prompted the Commission to impose directions in lieu of a financial penalty was the fact that at the material time, such health declaration information was widely collected across the island. There was also a corresponding acceptance and support from members of the public of the need for the collection of such health declaration information in order for the relevant authorities to effectively respond to and control the potential spread of COVID19. 16. Given the above, the Commission directs the Organisation to carry out the following within 60 days: a. In relation to the Organisation’s remedial action of reviewing its application deployment process to take into consideration data security, i. The Organisation shall ensure that the intended measures include arrangements for reasonable pre-launch security testing 6 to be conducted before the launch of any new website, application, portal or other online feature for the processing of personal data; and ii. The Organisation shall ensure that the intended measures include the development and implementation of a data retention policy to meet the Retention Limitation Obligation under section 25 of the PDPA. b. In relation to the Organisation’s remedial action of scanning the Dark Web for evidence of exfiltration of the personal data, i. The Organisation shall conduct a scan of the Clear/Surface Web, as well as a renewed scan of the Dark Web to confirm that there is no evidence of publication of the affected personal data online. c. By no later than 14 days after the above actions have been carried out, the Organisation shall submit to the Commission a written update providing details of the actions taken. The following provision(s) of the Personal Data Protection Act 2012 had been cited in the above summary: Protection Obligation 24(a) Failure to protect personal data in its possession or under its control by making reasonable security arrangements to prevent – 7 (a) unauthorised access, collection, use, disclosure, copying, modification, disposal or similar risks 8 ",Directions,2e2e404473e7fa064a0c51315f167b10b4810806,"[""tags"",""decision"",""pdf-url"",""description"",""date"",""timestamp"",""url"",""title"",""nature"",""pdf-content""]" 2023-10-01T11:02:10+08:00,fbd32491db44d3d0c97aa12a99cefd61ec954264,16,16,1,1016,"A financial penalty of $72,000 was imposed on RedMart for failing to put in place reasonable security arrangements to protect the personal data in its possession or under its control.","[""Protection"", ""Financial Penalty"", ""Wholesale and Retail Trade""]",2022-12-19,https://www.pdpc.gov.sg/-/media/Files/PDPC/PDF-Files/Commissions-Decisions/Decision---RedMart-Limited---28102022.pdf,Protection,Breach of the Protection Obligation by RedMart,https://www.pdpc.gov.sg/all-commissions-decisions/2022/11/breach-of-the-protection-obligation-by-redmart,2022-12-19,"PERSONAL DATA PROTECTION COMMISSION Case No. DP-2010-B7266 In the matter of an investigation under section 50(1) of the Personal Data Protection Act 2012 And RedMart Limited … Organisation DECISION RedMart Limited [2022] SGPDPC 8 Lew Chuen Hong, Commissioner — Case No. DP-2010-B7266 28 October 2022 Introduction 1 Many organisations rely on web-based application programming interfaces (“API”) to enable computers or computer programs to communicate and facilitate the sharing of data between them. API keys are in turn used to authenticate users seeking to access APIs. If an organisation fails to implement reasonable security measures to safeguard the security of their API keys, this may allow threat actors unauthorised access to large troves of data stored within multiple interconnected environments. 2 On 29 October 2020, the Personal Data Protection Commission (“the Commission”) was notified that a database containing personal data of the customers of RedMart Limited (the “Organisation”) was being offered for sale on an online forum (the “Incident”). Subsequently, the Commission commenced investigations to determine whether the circumstances relating to the Incident disclosed any breaches by the Organisations of the Personal Data Protection Act 2012 (“PDPA”). Facts of the Case 3 The Organisation operated an online platform selling groceries and fresh produce to consumers. In 2016, the Organisation was acquired by Lazada Group (“Lazada”). Thereafter, 2 the Organisation began to integrate its platform with Lazada’s online platform. The customerfacing website and mobile application ceased operations on 15 March 2019. However, on the back end, the migration and integration of the Organisation’s system into Lazada’s system was not completed by that time. It is worth setting out in some detail the Organisation’s information technology architecture to understand the backdrop against which the Incident occurred. 4 From March 2012 until its acquisition by Lazada, the Organisation’s business applications (including its customer facing website, mobile application, warehouse and delivery back-end applications) were stored in RedMart’s Amazon Web Services Virtual Public Cloud (the “AWS Environment”). The personal data of its customers and sellers were in turn, always stored in a MongoDB database within RedMart’s Alibaba Virtual Public Cloud. Whilst the MongoDB database is stored within cloud infrastructure that belongs to the Alibaba Group, the Organisation remained responsible for managing its cloud environment (hereinafter, the “RedMart Cloud”). The Organisation did not encrypt the MongoDB database, or implement any password authentication requirement to access the MongoDB database. 5 After its acquisition, the Organisation’s intention was to re-design and migrate all the relevant databases and applications from the AWS Environment into the RedMart Cloud to facilitate its integration with Lazada’s systems and environment by March 2021. However, given the substantial time and resources required to complete the re-design and migration, the Organisation opted to carry out the migration in stages. Following the acquisition and as a matter of priority, the Organisation migrated its front end, customer-facing systems to the RedMart Cloud to enable a seamless integration into Lazada’s environment and platform for its customers. This was completed on 15 March 2019, after which the Organisation shut down its public-facing consumer application and website. Additionally, the MongoDB database residing in the RedMart Cloud containing the affected customer and seller data was 3 disconnected from the application and website (the “Affected Database”), and thereafter access by the Organisation’s customers was disabled. In contrast, the Organisation’s back-end business applications and systems (such as 6 order fulfilment, inventory, transport and warehousing) and its seller portal continued to be hosted on the AWS Environment and linked to the Affected Database contained in the RedMart Cloud. 7 Concomitantly, the Organisation’s back-end systems and IT infrastructure during the interim period was structured in the following manner: (a) The Organisation’s GitHub Enterprise repositories (the “GitHub Repositories”), were accessible by the Organisation’s employees possessing GitHub user and administrative accounts. The Organisation used the GitHub Repositories to store, amongst other things, sensitive source codes including a Chef1 key that functioned as a high privilege access key to the AWS Environment. The Organisation implemented the following access control measures vis-à-vis the GitHub Repositories: i. For GitHub user accounts, the Organisation followed GitHub’s password policy, which required the use of passwords which were either eight characters long if it included a number and a lowercase letter, or 16 characters long with any combination of characters; and ii. For GitHub administrator accounts, two-factor authentication (“2FA”) was required on top of the password requirements above. “Chef” is an orchestration tool used for automated provisioning and management purposes within an AWS environment. 1 4 (b) The AWS Environment was accessible through the Chef key, and contained various private Simple Storage Service (“S3”) buckets 2 , one of which contained another sensitive API key – the Hubot3 key. (c) Lastly, the AWS Environment was connected to the RedMart Cloud through an OpenVPN4 connection. The Affected Database was stored within the RedMart Cloud. The Incident 8 Sometime in September 2020, an unidentified threat actor (“TA”) gained unauthorised access to the GitHub user account of a member of the Organisation’s DevOps (i.e. software development and IT operations) team. The TA utilised the compromised GitHub user account to search through the GitHub Repositories and found the Chef key. Thereafter the TA used the Chef key to access the AWS Environment, whereupon he scanned through the Organisation’s private S3 buckets and located the Hubot key. 9 Using the Hubot key, the TA created a rogue Amazon Elastic Compute Cloud (“EC2”) instance in the AWS Environment. The TA also created a new firewall rule to enable a connection between the rogue EC2 instance and another part of the Organisation’s network hosted by the RedMart Cloud. The TA then traversed the OpenVPN connection (that linked the AWS Environment to the RedMart Cloud) to access the RedMart Cloud. 10 Once the TA had gained access to the RedMart Cloud, he proceeded to exfiltrate the Affected Database on 6 September 2020. Subsequently, the Affected Database was found on an online forum being offered for sale. 2 S3 buckets are public cloud storage resources in AWS which are similar to file folders. Hubot is a chat software that can be scripted to interact with an IT environment. 4 OpenVPN is a virtual private network system that implements techniques to create secure point-to-point or site-to-site connections in routed or bridged configurations and remote access facilities. 3 5 11 The Affected Database contained the following personal data: Customer accounts Seller business accounts Number of affected 898,791 individuals Types of personal a. Name a. Partial credit card number data b. Email address comprising first 6 and last c. Contact number 4 digits d. Residential address e. Partial credit card details b. Hashed account password comprising: • First 6 and last 4 digits of card number • Card owner’s name • Expiry date • Credit card billing phone number and billing address • Hashed account password • URL links of call recordings between customer service agents and the Organisation’s customers Remedial actions 12 Following the Incident, the Organisation and Lazada implemented the following remedial measures: Actions to mitigate the effects of the Incident (a) Disabled and reset the affected Chef and Hubot keys. (b) Disabled the compromised GitHub user account. 6 (c) Reset all other existing AWS API keys, GitHub user credentials and tokens (d) Deleted the EC2 instance created by the TA. (e) Logged out and reset of all affected customer and seller accounts on 30 October 2020. (f) Reviewed all of the Organisation’s servers with services connected to Internet. All sensitive services were filtered by a firewall. (g) Conducted vulnerability scanning of 31 Internet facing IP addresses. (h) Investigated all other existing MongoDB databases to search for traces of the TA. (i) Monitored the Lazada login page for brute force attacks. (j) Informed all affected individuals of the Incident via emails and broadcast on the Lazada online and application platforms on 30 October 2020. A media statement was also issued at the same time. Actions to prevent recurrence of the Incident or similar incidents (k) Implemented database authentication for all databases containing personal data. Restricted access to sensitive database from only authorised source IP addresses instead of network ranges. (l) Implemented 2FA for all GitHub accounts and removed unnecessary GitHub accounts and developer access keys. (m) Scanned for vulnerabilities in AWS critical Virtual Private Cloud instances. 7 (n) Performed a security architecture review of the Organisation’s multiple cloud network and intra-cloud micro-segmentation. (o) Reviewed all AWS Identity and Access Management user permissions to ensure no “create instance” permission. (p) Set up identity access management rules to restrict geographical locations from which API keys could be used to access the Organisation/Lazada cloud environments. (q) Reviewed all user identities and access privileges for all systems and applications used. Removed access privileges of all inactive accounts. (r) Implemented network traffic logging between the AWS Environment and RedMart Cloud. (s) Implemented network Access Control list and endpoint detection and response for windows instances for RedMart Cloud. (t) Implemented security monitoring to detect creation of any new cloud instance (u) Enabled Virtual Private Cloud (VPC) logs for security monitoring. (v) Required all of the Organisation’s employees to complete an online training course on privacy management and responsibilities in handling personal data. Findings and Basis for Determination The Protection Obligation under section 24 of the PDPA 8 13 Based on the circumstances of the Incident as set out above, the Commission’s investigation focused on whether the Organisation had breached its obligation under section 24 of the PDPA to protect personal data in its possession or under its control by taking reasonable security steps or arrangements to prevent unauthorised access and disclosure (“the Protection Obligation”). 14 In determining what constitutes reasonable security steps or arrangements, an organisation should have regard to the nature of the personal data in its possession and control, as well as the impact that the disclosure of the data might have on the affected persons. As stated in the Commission’s Advisory Guidelines on Key Concepts in the PDPA (the “Advisory Guidelines”)5 at [17.2]: “There is no ‘one size fits all’ solution for organisations to comply with the Protection Obligation. Each organisation should consider adopting security arrangements that are reasonable and appropriate in the circumstances, for example, taking into consideration the nature of the personal data, the form in which the personal data has been collected (e.g. physical or electronic) and the possible impact to the individual concerned if an unauthorised person obtained, modified or disposed of the personal data. For example, in the employment context, it would be reasonable to expect a greater level of security for highly confidential employee appraisals as compared to more general information about the projects an employee has worked on.” (emphasis added) 15 Given the high volume of personal data contained in the Affected Database (approximately 898,791 individuals, encompassing personal data such as names, email 5 https://www.pdpc.gov.sg/guidelines-and-consultation/2020/03/advisory-guidelines-on-key-concepts-in-thepersonal-data-protection-act 9 addresses, residential addresses, contact numbers and partial credit card details), it was incumbent on the Organisation to implement policies and practices that were commensurate with the Organisation’s higher-level security needs to discharge its obligation under the Protection Obligation. 16 For the reasons set out below, it is determined that the Organisation failed to implement reasonable security arrangements to protect the Affected Database from the risk of unauthorised access. Whether the Organisations had contravened the Protection Obligation 17 Based on the Organisation’s IT architecture as detailed above, the Affected Database was placed behind various levels of security controls within RedMart Cloud. This meant that a threat actor had to get through various access points to access the Affected Database. The implementation of network segmentation as part of layered defence is a reasonable strategy for defence-in-depth. However, a complex IT architecture can be defeated by simple errors, especially when the high-value data embedded within such complex systems are so often the target of sophisticated threat actors. The complexity of the Organisation’s network architecture does not paper over the cracks in its security arrangements – at every level of defence, the Organisation’s systems presented clear vulnerabilities that should have been addressed. 18 First, the Organisation failed to implement reasonable access control on its employers’ user GitHub accounts, which allowed the TA access to the GitHub Repositories. As stated in paragraph [7(a)], the access control measures were more stringent for GitHub administrative accounts than for GitHub user accounts. While this adequately dealt with the differentiation of ability to make configuration and other changes to the Organisation’s GitHub Repositories, it did not make any distinction to the type of data stored within the repositories. This disparity in 10 access controls was not sensitive to the fact that both types of accounts had equal abilities to access important files within the GitHub Repositories including the Chef key, which provided access to the AWS Environment. Data with higher security implications (such as the Chef Key) ought to be secured to a higher degree than other types of data. It is, of course, open to the Organisation to secure all data in its GitHub Repositories at the higher level. Indeed, as stated in paragraph 12(l), the Organisation and Lazada, as part of their remedial measures postIncident, implemented 2FA for all its GitHub accounts. 19 Second, the Organisation did not implement sufficient access controls to protect and limit access to the Chef and Hubot keys, which enabled highly privileged access to various environments within the Organisation’s systems. Not all accounts need access to the Chef and Hubot keys; and even for accounts that had access to them, they ought to be periodically reviewed to determine whether continued access were necessary. At an organisation-wide level, investigations revealed that the Organisation did not conduct periodic management reviews to ensure that the access to Chef and Hubot keys were limited to the GitHub accounts that required such access, or to remove access from accounts that no longer needed it (including removing unnecessary GitHub accounts altogether). This is a fundamental data security practice. As suggested in the Commission’s Guide to Data Protection by Design for ICT Systems6: “12. Regularly review user accounts This ensures that all user accounts are legitimate. There should be processes to update or remove user accounts, for instance, when a user has left the organisation. Test accounts should also be removed after test activities have been completed. 6 https://www.pdpc.gov.sg/-/media/Files/PDPC/PDF-Files/Other-Guides/Guide-to-Data-Protection-by-Designfor-ICT-Systems-(310519).ashx?la=en 11 Separately, there should also be a process to review user accounts regularly. The review should include ensuring all the rights assigned are indeed necessary.” (emphasis added) 20 In this connection, best practice dictates that the principle of least privilege should apply i.e. each employee be given only the minimum level of access rights or privileges necessary for that employee to complete an assigned operation. This would limit the damage in case a vulnerability is exploited, as in this case where the TA gained unauthorised access to a GitHub user account. This principle was also espoused in GitHub’s own Secure Design Principles7. The Organisation’s failure to limit access to the Chef and Hubot keys at the material time allowed the TA to access the Chef key, and consequently the AWS Environment, through a GitHub user account. 21 On a more granular level, insufficient security measures were implemented to protect the Chef and Hubot keys, as both were stored in plain text files that were not encrypted or even password-protected. Specifically: (a) The Chef key was hardcoded in source code and stored in the GitHub repositories, and was accessible to a large group of developers from the Organisation, Lazada and Alibaba for the purpose of knowledge sharing. By allowing so many accounts to access the Chef key in such a manner, the risk of exposure and exploitation was heightened. (b) The Hubot key was stored in plain text in an AWS private S3 bucket. Therefore, any account that accesses the AWS Environment was able to access the Hubot key as a 7 https://github.com/OWASP/DevGuide/blob/master/02Design/01Principles%20of%20Security%20Engineering.md 12 conduit from which to access the RedMart Cloud and the Affected Database stored therein. 22 The manner in which the Chef and Hubot keys were stored in the GitHub Repositories and AWS Environment were manifestly inadequate in view of the circumstances, and this vulnerability was exploited by the TA to access the keys after he gained access to the GitHub Repositories and AWS Environment respectively. Ideally, such keys ought to be stored in a separate location such as Secrets Manager within the AWS Environment (i.e. a dedicated key vault). The Organisation should not have embedded the Chef and Hubot keys directly in the source code. This is also reflected in AWS Access Keys best practices8, which the Organisation should have been aware of given its usage of the AWS Environment since 2012: “Observe these precautions when using access keys: • Don't embed access keys directly into code. The AWS SDKs and the AWS Command Line Tools enable you to put access keys in known locations so that you do not have to keep them in code.” (emphasis added) 23 Such best practices applies to of all platforms that use APIs, and are not confined to AWS. They are echoed in Google’s best practices for securely using API keys9, which are meant to apply to Google Cloud but are nevertheless apposite here: 8 https://docs.aws.amazon.com/general/latest/gr/aws-access-keys-best-practices.html https://support.google.com/googleapi/answer/6310037?hl=en#:~:text=Delete%20unneeded%20API%20keys% 3A%20To,use%20the%20newly%2Dgenerated%20keys 9 13 “Best practices for securely using API keys When you use API keys in your Google Cloud Platform (GCP) applications, take care to keep them secure. Publicly exposing your credentials can result in your account being compromised, which could lead to unexpected charges on your account. To keep your API keys secure, follow these best practices: • Do not embed API keys directly in code: API keys that are embedded in code can be accidentally exposed to the public, for example, if you forget to remove the keys from code that you share. Instead of embedding your API keys in your applications, store them in environment variables or in files outside of your application's source tree. • Do not store API keys in files inside your application's source tree: If you store API keys in files, keep the files outside your application's source tree to help ensure your keys do not end up in your source code control system. This is particularly important if you use a public source code management system such as GitHub. • Restrict your API keys to be used by only the IP addresses, referrer URLs, and mobile apps that need them: By restricting the IP addresses, referrer URLs, and mobile apps that can use each key, you can reduce the impact of a compromised API key. You can specify the hosts and apps that can use each key from the GCP Console Credentials page and then create a new API key with the settings you want, or edit the settings of an existing API key. • Restrict your API keys to be usable only for certain APIs: If you have multiple APIs enabled in your project and your API key should only be used with some of them, restrict usage of that key to those APIs. You can specify the allowed 14 APIs for each key from the GCP Console Credentials page and then create a new API key with the settings you want, or edit the settings of an existing API key. • Delete unneeded API keys: To minimize your exposure to attack, delete any API keys that you no longer need. • Regenerate your API keys periodically: You can regenerate API keys from the GCP Console Credentials page by clicking Regenerate key for each key. Then, update your applications to use the newly-generated keys. Your old keys will continue to work for 24 hours after you generate replacement keys.” (emphasis added) 24 The Organisation claimed that it was constrained from implementing password protection and encryption for the Chef and Hubot keys by technical issues, and that the implementation of password protection or encryption was not feasible or practical given the keys’ core administrative and automating technical functions. The mere existence of technical issues does not exculpate the Organisation, or justify the Organisation’s decision to embed the Chef and Hubot keys into source code. Technical issues are not insurmountable, and it is open to the Organisation to expend the necessary time, effort and resources to troubleshoot and resolve them. However, investigations revealed that the Organisation did not make sufficient efforts to resolve the technical issues in a timely manner, and were thus responsible for its difficulties in implementing access controls for the Chef and Hubot keys. More broadly, even if the Chef and Hubot keys were not compatible with password protection or encryption, there were a variety of other methods available to safeguard the security of the keys as set out in the best practices set out above, such as removing unnecessary GitHub accounts, restricting access to only certain GitHub administrative accounts or storing the keys separately in a configuration 15 file or a key vault. Nothing prevented RedMart from adhering to such best practices, as is evident by the fact that all these measures were implemented after the Incident occurred. 25 Lastly, the Organisation also did not implement separate authentication requirements, for the Affected Database. Once the TA accessed the RedMart Cloud, this enabled the TA to access and exfiltrate the Affected Database. Instead, the only measures implemented to safeguard the Affected Database were the access requirements for the RedMart Cloud environment in general, which was circumvented by the TA through his possession of the Hubot key. This reflects a failure of the Organisation’s attempt to deploy a reasonable “defence in depth” strategy (despite its multiple layers of access) to safeguard the security of the Affected Database, as it should have implemented separate authentication requirements for the Affected Database to prepare for the contingency of someone gaining unauthorised entry into the RedMart Cloud. 26 At a basic level, this should have included access controls such as password protection. Further, given the high volume of personal data contained in the Affected Database, the Organisation should also have taken steps to implement more stringent access controls, such as limiting access only to certain authorised network connections / interfaces. The Center for Internet Security MongoDB 5 Benchmark10 recommends requiring authentication of, amongst others, users and servers before allowing access to a MongoDB database on the following basis: “2 Authentication This section contains recommendations for requiring authentication before allowing access to the MongoDB database. 10 https://cissecurity.org/benchmark/mongodb 16 … Rationale: Failure to authenticate clients, users, servers can enable unauthorized access to the MongoDB database and can prevent tracing actions back to their sources. It's highly recommended that password length and complexity also be in-place. When performing the traditional user/password authentication against MongoDB there is not in-place intrinsic password complexity check and there is no LOCKING mechanism with multiple failure logins. So, MongoDB is prone to brute force attacks compared to other database systems.” (emphasis added) 27 The Organisation, again, cited technical difficulties for why separate authentication requirements were not implemented for the Affected Database. Again, such technical difficulties could have been overcome if the Organisation had expended the effort and resources to do so. The Commissioner’s Decision 28 In determining whether any directions should be imposed on the Organisation under section 48I of the PDPA, and/or whether the Organisation should be required to pay a financial penalty under section 48J of the PDPA, the factors listed at section 48J(6) of the PDPA were considered, with particular emphasis on the following mitigating factors: (a) the Organisation was cooperative with the Commission’s investigations, responding to the Commission’s queries in a prompt and forthcoming manner; 17 (b) the Organisation had put in place some good data de-identification practices for the credit card numbers in its possession by redacting part of the data and storing only partial credit card details. This reduced the sensitivity and harm that might be caused when personal data within its control are disclosed in a data breach; and (c) the Organisation swiftly implemented effective measures to mitigate the effects of the incident and prevent recurrences. 29 The Organisation was notified of the preliminary decision by way of the Commission’s letter dated 2 August 2022 and was invited to make representations. Representations Made by the Organisation 30 On 23 August 2022, the Organisation made the following representations to the Commission seeking a reduction in the financial penalty: (a) The Organisation had voluntarily notified the Commission and affected individuals of the Incident even though it was not legally obliged to do so at the material time, as the Data Breach Notification Obligation under Part 6A of the PDPA only came into effect on 1 February 2022; (b) As of the date of the representations, the Organisation was not aware of any personal data of the affected individuals being misused as a consequence of the Incident. In support, the Organisation stated that the data in the Affected Database relates to data used on its previous application and website which is no longer in use. Moreover, the data was more than 18 months out of date, and was not linked to any current Lazada databases. Although the Organisation’s account passwords had been securely encrypted at the time of the Incident, it had conducted a forced logout and 18 password reset on every affected current Lazada account upon discovery of the Incident to ensure that no third party could misuse the leaked passwords by logging into a current Lazada account; and (c) The Incident was the Organisation’s first breach of the PDPA. To the best of the Organisation’s knowledge and belief, the Incident was its first experience of a data breach. Voluntary notification 31 The Commission had already taken into account the Organisation’s voluntary notification of the Incident into account in determining the quantum of the financial penalty in the preliminary decision. Hence, this factor does not warrant a further reduction in the financial penalty imposed. Lack of misuse of the affected personal data 32 The fact that the Organisation was not aware of any misuse of the affected personal data is neither here or there, and does not merit a further reduction in the financial penalty. Whilst evidence of exploitative use may be a relevant factor of harm that may be relevant for enhancing the financial penalty, the inverse is not necessarily true. 33 In support of its representations, the Organisation cited the case of Learnaholic Pte Ltd [2019] SGPDPC 31 (“Learnaholic”), in which the Commissioner had taken into account the fact that “while there was actual exfiltration of the Personal Data…there was no evidence of further exploitation, use or disclosure of the Personal Data by the attacker”.11 It suffices to 11 Learnaholic at [34]. 19 say that the Commission has explained Learnaholic in Farrer Park Hospital Pte Ltd [2022] SGPDPC 6 at [35 to 36] as follows: “35 In the case of Learnaholic the main factors taken into account when deciding to reduce the preliminary financial penalty imposed were: (a) A reduction in the total number of affected individuals due to a recalculation of figures; and (b) The benefit of doubt given to Learnaholic as to the period of time the vulnerability in its system existed. 36 The lack of evidence of further exploitation, use or disclosure is not, ipso facto, a factor meriting a reduction of the financial penalty. The Organisation’s representations are not accepted as the lack of an aggravating factor (i.e. subsequent exploitation, use or disclosure of personal data) is not in itself a mitigating factor.” 34 The explanation in Farrer Park Hospital that is cited above is equally applicable in the present case. Lack of antecedents 35 In calibrating the financial penalty in the preliminary decision, the Commission had already taken into account the fact that this was the Organisation’s first non-compliance with the PDPA, and no further reduction is merited. In support of its representations, the Organisation also cited Aviva Ltd and Toh-Shi Printing Singapore Pte Ltd [2016] SGPDPC 15 (“Aviva""), where the Commission had taken into account the fact that the breach of the Protection Obligation by the organisation was its second breach in approximately one year, and both data breach incidents involved similar fact patterns and causes. 12 In Aviva, the Commission had considered the organisation’s previous non-compliance as a contributory 12 Aviva at [38(c)]. 20 factor that justifies an increase in the financial penalty meted as the organisation had failed to improve its data protection practices. In contrast, the lack of antecedents in this instance means that the Commission did not increase the financial penalty imposed on the Organisation. To be clear, the absence of an antecedent does not, ipso facto, merit a reduction in the financial penalty imposed. Acceptance of the Commission’s findings 36 Notwithstanding the foregoing, the Commission notes that the Organisation voluntarily accepted the Commission’s findings in the preliminary decision, that it had failed to comply with the Protection Obligation and explicitly indicated that it would not seek to challenge these findings. The Organisation’s voluntary acceptance of liability (even at this late stage) ought to be reflected in the financial penalty. Had the Organisation accepted responsibility for the Incident at an earlier stage of the investigation, it could have significantly shortened the time for investigations and resolution of this case through the expedited breach procedure and also benefited from greater mitigatory considerations. Nonetheless, an organisation that voluntarily accepts responsibility for its non-compliance with the PDPA should be recognised as an organisation that demonstrates its commitment to the Accountability Obligation and shows that it can be responsible for the personal data in its possession or under its control.13 37 Having considered all the relevant factors in this case, the Commission hereby requires the Organisation to pay a financial penalty of $72,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. 13 Refer to section 11(2) of the PDPA. 21 38 In view of the remedial actions already been taken by the Organisation, no further directions need be issued to the Organisation. YEONG ZEE KIN DEPUTY COMMISSIONER FOR COMMISSIONER FOR PERSONAL DATA PROTECTION 22 ",Financial Penalty,1f2e2b94601c32c373eb88020422ba071c772e63,"[""tags"",""decision"",""pdf-url"",""description"",""date"",""timestamp"",""url"",""title"",""nature"",""pdf-content""]" 2023-10-01T11:02:10+08:00,fbd32491db44d3d0c97aa12a99cefd61ec954264,17,17,1,1016,Directions were issued to both Shopify Commerce Singapore and Supernova to put in place a process to ensure compliance with the Transfer Limitation Obligation following a data breach incident of Shopify Inc's database.,"[""Transfer Limitation"", ""Directions"", ""Others"", ""Data Intermediary""]",2022-11-18,https://www.pdpc.gov.sg/-/media/Files/PDPC/PDF-Files/Commissions-Decisions/GD_Supernova-Pte-Ltd_06102022.pdf,Transfer Limitation,Breach of the Transfer Limitation Obligation by Shopify Commerce Singapore and Supernova,https://www.pdpc.gov.sg/all-commissions-decisions/2022/11/breach-of-the-transfer-limitation-obligation-by-shopify-commerce-singapore-and-supernova,2022-11-18,"PERSONAL DATA PROTECTION COMMISSION [2022] SGPDPC 7 Case No: DP-2103-B8147 / DP-2206-B9935 In the matter of an investigation under section 50(1) of the Personal Data Protection Act 2012 And (1) Supernova Pte Ltd (2) Shopify Commerce Singapore Pte Ltd … Organisation DECISION Page 1 of 12 Supernova Pte Ltd & Anor Yeong Zee Kin, Deputy Commissioner — Case No. DP-2103-B8147/ DP-2206-B9935 6 October 2022 Introduction 1 On 8 October 2020, the Personal Data Protection Commission (the “Commission”) was notified by Supernova Pte Ltd (“SNPL”) of a data breach incident of Shopify Inc’s database affecting the personal data of certain Singapore-based customers (the “Incident”). The Commission commenced investigations to determine whether the circumstances relating to the Incident disclosed any breaches of the Personal Data Protection Act 2012 (“PDPA”). Facts of the Case Background 2 Shopify Inc (“Shopify”) is a company based in Canada that operates an e- commerce platform for online retailers to conduct sales (the “Platform”). SNPL is an online retailer that began using the Platform in 2018 to sell its products to customers. Shopify provided payment processing and other services (the “Services”) to SNPL pursuant to the Shopify Plus Agreement, executed by Shopify and SNPL on 4 December 2018. Shopify Commerce Singapore Pte Ltd (“Shopify SG”) acted as the Page 2 of 12 Asia-Pacific data sub-processor of Shopify pursuant to the Shopify Data Processing Addendum to the Shopify Plus Agreement, and its role was confined to collecting customer personal data (including SNPL’s) via the Platform and transferring the data out of Singapore to Shopify for both Purchase Processing and Platform Processing. 3 The Platform collected personal data from customers of its online retailers for two broad sets of purposes. First, to facilitate billing, payment and shipping on behalf of the Platform’s online retailers (“Purchase Processing”). Second, for Shopify’s own commercial and administrative purposes. This mainly included the collection of consumer personal data through the Platform’s own consumer-facing applications and services e.g. Shop Pay (collectively, “Platform Processing”). Granted, for Platform Processing, users of the Platform included customers of merchants who are on the Platform, such as SNPL’s customers. Nevertheless, customer personal data was being collected and processed by Shopify for its own purposes, and not on behalf of merchants. 4 On 1 July 2019, the Shopify Plus Agreement (including the Shopify Data Processing Addendum) was assigned to Shopify SG (the “Assignment”). At the material time, SNPL had no knowledge of the Assignment as no notice of assignment was required. Consequently, the relationship between the parties was reconfigured in the following manner: (a) For Purchase Processing, Shopify SG became the data intermediary of SNPL, and was responsible for processing personal data on behalf of SNPL. Page 3 of 12 The flow of SNPL’s customer personal data did not change - Shopify SG continued to collect SNPL’s customer personal data and transferred this to Shopify to carry out Purchase Processing on its behalf. (b) For Platform Processing, Shopify SG became the data controller of the customer personal data collected through the Platform and its customer-facing applications, including the personal data of the customers of merchants who use the Platform (such as SNPL). In such circumstances, personal data from such users are collected by Shopify SG and processed for its purposes and not on behalf of the merchants. The flow of customer personal data also did not change, as Shopify SG continued to transfer personal data of users of its Platform to Shopify to carry out Platform Processing. The Incident 5 Between June to September 2020, two Philippines-based service contractors of Shopify that were engaged through a third party, illegally accessed and exfiltrated certain customer personal data stored in Shopify’s systems, which had been collected via the Platform for Purchase Processing (the “Incident”). This included customer personal data of SNPL. Shopify became aware of this on 15 September 2020 and informed SNPL on 18 September 2020. 6 The customer personal data affected in the Incident included full names, email addresses, billing addresses, shipping addresses, phone numbers, bank identification Page 4 of 12 numbers, IP addresses, last 4 digits of the customer payment cards, and purchase histories of 23,928 individuals. Findings and Basis for Determination 7 Neither SNPL nor Shopify SG were responsible for the security of Shopify’s systems in Canada holding the personal data affected in the Incident. Nevertheless, both organisations were bound by section 26 of the PDPA. Transfer limitation obligation under section 26 of the PDPA 8 Section 26(1) of the PDPA provides that an organisation shall not transfer any personal data to a country or territory outside Singapore except in accordance with requirements prescribed under the PDPA to ensure that organisations provide a standard of protection to personal data so transferred that is comparable to the protection under the PDPA (the “Transfer Limitation Obligation”). The requirements applicable to the aforementioned transfers of personal data from SNPL and Shopify SG to Shopify were those prescribed in Part III of the Personal Data Protection Regulations 2014 (“PDPR 2014”)1. In particular: (a) Regulation 9(1)(b) of the PDPR 2014 requires an organisation that transfers personal data to a country or territory outside of Singapore to take appropriate steps to ensure that the recipient of the personal data is bound by legally 1 The PDPR 2014 governs the transfers of personal data prior to 1 February 2021. Transfers of personal data after 1 February 2021 are governed by the Personal Data Protection Regulations 2021. Page 5 of 12 enforceable obligations to provide to the transferred personal data a standard of protection that is at least comparable to that under the PDPA; and (b) Regulation 10(1)(b) and 10(1)(c) provide that such legally enforceable obligations include may be imposed on the recipient by contract or binding corporate rules (subject to Regulation 10(2) and 10(3) respectively). Breach of the Transfer Limitation Obligation by SNPL 9 When SNPL entered into the Shopify Plus Agreement on 4 December 2018, it was aware that by using the Platform its customer personal data would be transferred to Shopify, which was outside Singapore, for Purchase Processing. Shopify was SNPL’s data intermediary, whilst Shopify SG was Shopify’s data sub-processor as explained in paragraph 2. 10 SNPL (as the data controller of its customers’ personal data) had been notified, in the Shopify Plus Agreement, that its customer personal data may be transferred out of Singapore for the purpose of Purchase Processing, and was obligated to comply with the Transfer Limitation Obligation vis-à-vis the personal data collected by Shopify / Shopify SG for Purchase Processing. Section 4(3) of the PDPA provides that an organisation shall have the same obligation under the PDPA in respect of personal data processed on its behalf and for its purposes by a data intermediary as if the personal data were processed by the organisation itself. Such obligations include the Page 6 of 12 Transfer Limitation Obligation. As stated in the Commission’s Advisory Guidelines on Key Concepts in the PDPA2: “Considerations for organisations using data intermediaries 6.20 Section 4(3) 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 were processed by the organisation itself. As such, it is good practice for an organisation to undertake an appropriate level of due diligence to assure itself that a potential data intermediary is capable of complying with the PDPA. … Overseas transfers of personal data 6.22 Where an organisation engages a data intermediary to process personal data on its behalf and for its purposes, the organisation is responsible for complying with the Transfer Limitation Obligation in respect of any overseas transfer of personal data. This is regardless of whether the personal data is transferred by the organisation to an overseas data intermediary or transferred overseas by the data intermediary in 2 Advisory Guidelines on Key Concepts in the PDPA (Rev 1 October 2021) Page 7 of 12 Singapore as part of its processing on behalf and for the purposes of the organisation. 6.23 The Transfer Limitation Obligation requires that an organisation ensures that personal data transferred overseas is protected to a standard comparable with the Data Protection Provisions. The onus is on the transferring organisation to undertake appropriate due diligence and obtain assurances when engaging a data intermediary to ensure that it is capable of doing so. In undertaking its due diligence, transferring organisations may rely on data intermediaries’ extant protection policies and practices, including their assurances of compliance with relevant industry standards or certification.” (emphasis added) 11 The Transfer Limitation Obligation required SNPL to ensure, prior to transferring customer personal data for processing by Shopify, that Shopify provided a standard of protection to transferred personal data that was comparable to the protection under the PDPA. This obligation did not abate by virtue of the Assignment on 1 July 2019, even though SNPL claimed that it was not made aware of the Assignment. At all times, SNPL was responsible for complying with the Transfer Limitation Obligation for its transfer to Shopify (initially) and Shopify SG (latterly). Even though Shopify SG assumed legal responsibility as SNPL’s data intermediary Page 8 of 12 supposedly without informing SNPL, the flow of SNPL’s customer personal data was not altered, as Shopify SG continued to transfer SNPL’s customer personal data outside of Singapore (i.e. to Shopify) for Purchase Processing. 12 In connection with this, the onus laid with SNPL to put in place the relevant contractual clauses to ensure the protection of its personal data to a standard comparable to the PDPA. However, investigations revealed that SNPL did not do so. The omission to put in place contractual clauses to ensure such comparable protection began with the start of their commercial arrangement. SNPL stated that, in 2018, it carried out a due diligence assessment of Shopify’s approach to data protection before entering into the Shopify Plus Agreement and migrating its online retail activities to the Platform (“2018 Due Diligence Exercise”). However, this assessment was inadequate as it failed to ensure that there were binding contractual clauses requiring personal data transferred between them to be protected to a standard comparable to the PDPA. 13 Accordingly, SNPL failed to comply with the Transfer Limitation Obligation. Breach of the Transfer Limitation Obligation by Shopify SG 14 For the Purchase Processing of customer personal data discussed in the preceding paragraphs, Shopify SG acted as SNPL’s data intermediary and was thus not bound by the Transfer Limitation Obligation. Page 9 of 12 15 However, Shopify SG must also comply with the Transfer Limitation Obligation in relation to the personal data collected for Platform Processing. This is because Shopify SG was processing customer personal data for its own purposes, and was thus the data controller, while Shopify is the data intermediary. 16 In connection with this, investigations revealed that there were no legally binding obligations, in the form of contracts or binding corporate rules within the Shopify group, requiring Shopify to provide PDPA-comparable protection to personal data transferred from Shopify SG to Shopify for processing. While the Shopify Data Processing Addendum makes references to certain data protection legislation applicable to the European Union and the State of California, it did not cover the PDPA. During the course of investigations, Shopify indicated that it would “be putting in place binding corporate rules governing the transfer of merchants’ customers’ data between group entities” and furnished a draft APAC Cross-Border Whitepaper to the Commission. Whilst this was a step in the right direction, it did not retrospectively allow Shopify SG to regularise its intra-group data transfers to ensure compliance with the Transfer Limitation Obligation at the material time. 17 In view of the foregoing, Shopify SG failed to comply with the Transfer Limitation Obligation in respect of Platform Processing of personal data. The Deputy Commissioner’s Directions 18 In determining what directions (if any) should be given to the organisations pursuant to section 48I of the PDPA, and/or whether the Organisation should be Page 10 of 12 required to pay a financial penalty under section 48J of the PDPA, the factors listed at section 48J(6) of the PDPA were considered. In particular, the Commission placed emphasis on the fact that SNPL and Shopify SG had been highly cooperative with the Commission’s investigations. 19 On 18 July 2022, SNPL made representations to the Commission requesting for additional time to comply with the above direction. In consideration of SNPL’s limitations as a small and medium enterprise, SNPL’s deadline to comply with the direction is extended from 60 days to 6 months. 20 Having considered all the relevant factors of this case, SNPL is hereby directed to take the following actions: (a) SNPL is to put in place within 6 months a process to ensure compliance with the Transfer Limitation Obligation under section 26 of the PDPA in any future engagement of services that may involve the processing of personal data outside of Singapore on behalf of SNPL; and (b) Shopify SG is to put in place within 60 days a process to ensure compliance with the Transfer Limitation Obligation under section 26 of the PDPA in any future engagement of its services that may involve the processing of personal data outside of Singapore. 21 Specific to SNPL’s transfer of personal data for the purpose of Purchase Processing to Shopify in Canada, the following observations may be helpful. The Page 11 of 12 Association of Southeast Asian Nations (“ASEAN”) adopted and endorsed the Model Contractual Clauses (“ASEAN MCCs”), which are meant to facilitate cross-border transfers of personal data. These provide a standard for business-to-business (B2B) transfers that can be used by enterprises of any scale, but are especially helpful for small and medium enterprises. When using them, businesses may adapt these clauses as necessary for their commercial arrangements. 22 The Commission recognises the ASEAN MCCs as meeting the requirements of the Transfer Limitation Obligation under the PDPA: see PDPC’s Guidance for the Use of ASEAN Model Contractual Clauses for Cross Border Data Flows in Singapore (published 22 January 2021). Using the ASEAN MCCs can ease B2B transfers between Singapore and other jurisdictions such as Canada. In carrying out the directions, SNPL may therefore wish to consider relying on and adapting, as necessary, the ASEAN MCCs. YEONG ZEE KIN DEPUTY COMMISSIONER FOR PERSONAL DATA PROTECTION Page 12 of 12 ",Directions,a460c9f6da7d242e2c26bf56c9b5bc6bd47df7e7,"[""tags"",""decision"",""pdf-url"",""description"",""date"",""timestamp"",""url"",""title"",""nature"",""pdf-content""]" 2023-10-01T11:02:10+08:00,fbd32491db44d3d0c97aa12a99cefd61ec954264,18,18,1,1016,"A financial penalty of $58,000 was imposed on Farrer Park Hospital for failing to put in place reasonable security arrangements to protect the personal data in its possession or under its control.","[""Protection"", ""Financial Penalty"", ""Healthcare""]",2022-11-18,https://www.pdpc.gov.sg/-/media/Files/PDPC/PDF-Files/Commissions-Decisions/GD_Farrer-Park-Hospital-Pte-Ltd_15092022.pdf,Protection,Breach of the Protection Obligation by Farrer Park Hospital,https://www.pdpc.gov.sg/all-commissions-decisions/2022/11/breach-of-the-protection-obligation-by-farrer-park-hospital,2022-11-18,"PERSONAL DATA PROTECTION COMMISSION [2022] SGPDPC 6 Case No. DP-2007-B6646 In the matter of an investigation under section 50(1) of the Personal Data Protection Act 2012 And Farrer Park Hospital Pte Ltd … Organisation DECISION Farrer Park Hospital Pte Ltd Farrer Park Hospital Pte Ltd Lew Chuen Hong, Commissioner — Case No. DP-2007-B6646 15 September 2022 Introduction 1 On 23 July 2020, the Personal Data Protection Commission (the “Commission”) received a data breach notification from Farrer Park Hospital Pte Ltd (the “Organisation”). The Organisation discovered that between 8 March 2018 and 25 October 2019, 9,271 emails had been automatically forwarded from two employees’ (the “Employees”) Microsoft Office 365 work email accounts (the “Email Accounts”) to a third-party’s email address (the “Third Party”), thereby disclosing the personal data of 3,539 unique individuals (the “Incident”). Background 2 The Organisation is a private tertiary healthcare institute that provides a range of healthcare services. The nature of the Organisation’s operations requires its employees to regularly handle highly sensitive personal data of past, present, and prospective patients. At the material time, the Employees were part of the Organisation’s marketing department which, inter alia, processes requests for the Organisation’s medical services via email. The email requests received by the Organisation’s marketing department contain personal data pertinent to the medical treatment(s) requested by individuals including: (a) Name; (b) Gender; 1 Farrer Park Hospital Pte Ltd (c) Nationality; (d) Date of Birth; (e) NRIC Number (full and partial); (f) Passport details (including Passport numbers); (g) Contact number; (h) Photograph; and (i) Medical information, including the following (the “Medical Information”): (i) Medical Condition(s) – namely, patient’s health condition(s), including doctor’s diagnosis, brief description of the health condition provided by the patient or an appointment with a specialist for a specific condition mentioned; (ii) Medical History – namely, more than one record of a patient’s health condition(s). (iii) Medical Results/Reports – namely, documents containing a medical procedure or analysis (for example, X-Rays). (collectively, the “Affected Data Types”) Security measures prior to discovery of the Incident 3 At the time of the Incident, the Organisation had implemented various IT and data protection policies regulating the collection, use, disclosure, and protection of personal data, including: 2 Farrer Park Hospital Pte Ltd (a) A ‘Data Protection Handbook’ to provide awareness and assistance to its employees in complying with the Personal Data Protection Act 2012 (the “PDPA”); (b) A ‘Personal Data Protection Policy for Patient Records’ to outline the Organisation’s protocol for managing patients’ medical records as well as the relevant retention period of medical records; (c) An ‘IT Security Management Standards’ policy detailing the establishment, implementation, and management of the Organisation’s information security program to ensure the prevention, detection, containment, and correction of security breaches; (d) An ‘Access Control Standards’ policy setting out the Organisation’s standards relating to user accounts and password security settings; and (e) An ‘Acceptable Use Policy’ stipulating the Organisation’s rules governing the acceptable use of its IT resources, including access to emails, websites, the internet, and other types of organisational information, and which mandated that user passwords be at least 8 characters long, and contain characters from at least 3 of the below 4 categories 4 (i) “English upper-case letters (e.g., A, B, C, …Z)”; (ii) “English lower-case letters (e.g., a, b, C, …Z)”; (iii) “Alphanumeric (e.g., 1, 2, 3, …9)”; and (iv) “Special characters) (e.g., ?, !, %, $, #)”. The Organisation had also implemented various IT security measures and vendor-based solutions including: 3 Farrer Park Hospital Pte Ltd (a) Staff training sessions on medical confidentiality, and periodic email updates on developments to the PDPA and guidelines issued by the Commission; (b) Regular phishing exercises on employees to continually inculcate awareness on the techniques that malicious actors might deploy to undermine the organisation’s IT security; (c) A cloud-based filtering service to protect the Organisation against spam, malware, and other email threats; (d) Signature-based and behaviour-based endpoint protections to protect endpoints from known and unknown malicious files; (e) User and entity behaviour analytics utilising deep learning algorithms to identify anomalies based on the Organisation’s usual network traffic; (f) Webpage whitelisting solutions to only allow users to access permitted sites and/or category of sites based on the Organisation’s defined policies; (g) Firewalls to prevent unauthorised access into FPH’s private network; and (h) A network intrusion prevention system to analyse network traffic to prevent known malicious activities from occurring within the Organisation’s network. 5 At the time of the Incident, the work email accounts of the Organisation’s employees were hosted on Microsoft Office 365 (“Office 365”), and the Organisation’s employees were able to access their work email accounts through the internet via a web-browser (i.e. web-mail). In June 2019, the Organisation implemented multi-factor 4 Farrer Park Hospital Pte Ltd authentication (“MFA”) for all of its employees’ work email accounts as part of its planned initiatives. The MFA implemented by the Organisation required its employees to key in a one-time password sent to their registered mobile number when accessing their work email accounts from a new device (the “OTP Process”). Upon successfully accessing their work email account on that device, employees had the option of choosing to “stay signed in” to their work email account on that authenticated device. Where this option was chosen, employees would not be required to undergo the OTP Process when subsequently accessing their work email accounts on that same authenticated device. 6 The Organisation represented that the above security solutions did not detect any anomalies and/or unusual activities in the Organisation’s email traffic before 24 October 2019. The Incident 7 On 24 October 2019, the Organisation’s IT helpdesk received a complaint that one of the Email Accounts was not able to send outgoing emails. In conducting checks to address this complaint, the Organisation’s IT helpdesk discovered that Office 365 had automatically imposed restrictions on the Email Accounts. This is a security feature of Microsoft’s Exchange Online Protection which indicated unauthorised access to the Email Accounts. Further investigations by the Organisation confirmed that the Email Accounts had been configured to automatically forward all incoming emails to the Third Party. This auto-forwarding of emails occurred between 8 March 2018 to 25 October 2019 for one of the Email Accounts, and between 1 April 2018 to 25 October 2019 for the other. 8 In total, 9,271 emails were forwarded from the Email Accounts to the Third Party. This resulted in the unintended disclosure of personal data belonging to 3,539 5 Farrer Park Hospital Pte Ltd unique individuals, of which 1,923 unique individuals also had their Medical Information disclosed. The Affected Data Types were disclosed in different permutations and not all affected individuals had all of the Affected Data Types disclosed through the various forwarded emails. 9 For completeness, the MFA and OTP Process had been not implemented at the time when the Incident first occurred on 8 March 2018. Remedial Measures 10 After discovering the Incident, the Organisation carried out the following remedial measures: (a) Disabled the auto-forwarding feature for end-users; (b) Increased the frequency of internal cybersecurity training and exercises; (c) Implemented additional technical email and network security measures; and (d) Refreshed and upgraded various of its existing network security measures. 11 The Organisation has advised that it will by 2022, upgrade, refresh and/or enhance its existing solutions for its: (a) Network security measures; and (b) Endpoint security measures. 6 Farrer Park Hospital Pte Ltd Findings and Basis for Determination 12 In view of the circumstances of the Incident, the Commission’s investigation focused on whether the Organisation had breached its obligation under section 24 of the PDPA to protect personal data in its possession or under its control by making reasonable security arrangements to prevent unauthorised access, collection, use, disclosure, copying, modification, disposal, or similar risks (the “Protection Obligation”). 13 In deciding what constitutes reasonable security arrangements and/or controls, organisations should take into consideration the nature of the personal data in question, as well as the impact that disclosure of that personal data might have on affected person(s). This is a fact-specific assessment that organisations should undertake when developing and/or implementing its security arrangements, policies, and controls. As stated in the Commission’s Advisory on Key Concepts in the PDPA1: “There is no ‘one size fits all’ solution for organisations to comply with the Protection Obligation. Each organisation should consider adopting security arrangements that are reasonable and appropriate in the circumstances, for example, taking into consideration the nature of the personal data, the form in which the personal data has been collected (e.g. physical or electronic) and the possible impact to the individual concerned if an unauthorised person obtained, modified or disposed of the personal data. For example, in the employment context, it would be reasonable to expect a greater level of security for highly confidential employee appraisals as compared to more general information about the projects an employee has worked on. 1 See sections 17.2 – 17.3 of Advisory Guidelines on Key Concepts in the PDPA (Rev 1 February 2021) 7 Farrer Park Hospital Pte Ltd In practice, an organisation should: a) design and organise its security arrangements to fit the nature of the personal data held by the organisation and the possible harm that might result from a security breach; b) identify reliable and well-trained personnel responsible for ensuring information security; c) implement robust policies and procedures for ensuring appropriate levels of security for personal data of varying levels of sensitivity; and d) be prepared and able to respond to information security breaches promptly and effectively. In addition, it might be useful for organisations to undertake a risk assessment exercise to ascertain whether their information security arrangements are adequate. In so doing, the following factors may be considered: a) the size of the organisation and the amount and type of personal data it holds; b) who within the organisation has access to the personal data; and c) whether the personal data is or will be held or used by a third party on behalf of the organisation.” [emphasis added] 8 Farrer Park Hospital Pte Ltd 14 For the reasons set out below, it is determined that the Organisation failed to implement reasonable security arrangements to protect the personal data in the Email Accounts from the risk of unauthorised access and disclosure. Failure to put in place reasonable security arrangements to meet its needs 15 Where the personal data in question is sensitive and/or may cause damage to affected individuals if compromised, organisations should implement stronger access and security measures. The Commission has issued guidance on this issue in its Guide to Securing Personal Data in Electronic Medium2 (the “Guide”) In particular, paragraphs 7.3 and 7.4 of the Guide state that: “7. 3. The strength of authentication, such as password requirements or other mechanisms for access to personal data, should depend on the potential damage to the individual, such as potential damage to reputation or finances, if such personal data is compromised… 7.4 More secure authentication methods include two-factor or multi-factor authentication. These involve the use of a combination of information that the user knows, such as a password or PIN, and an object that only the user possesses, such as a digital key, token or smart card, or a unique physical trait, such as the use of fingerprints in biometric technology. The use of multi-factor authentication increases confidence in the identity of the user accessing the system.” [emphasis added] 2 Guide to Securing Personal Data in Electronic Medium (revised Jan 2017) 9 Farrer Park Hospital Pte Ltd 16 The Commission’s latest Guide to Data Protection Practices for ICT Systems3 also recommends two tiers of (i) basic and (ii) enhanced data protection practices for organisations to adopt in different circumstances. The guidance remains that larger quantities and more sensitive personal data call for enhanced data protection practices: “…For organisations that hold large quantities of different types of personal data or data that might be more sensitive to the individuals or organisations, they should additionally implement the relevant enhanced practices suggested.... The design and implementation of these protection measures should always take into consideration the extent of the sensitivity of the data based on the nature of business and types of services offered.”4 17 In the present case, the Organisation ought to have implemented stronger security arrangements, policies and/or controls to manage its marketing department’s Office 365 work email accounts, for the following reasons: (a) The Organisation’s marketing department routinely (on a daily basis) received and processed sensitive personal data, namely, the Medical Information of past, present and prospective patients. (b) The volume of sensitive personal data processed by the Organisation’s marketing department was not insignificant (1,923 individuals’ Medical Information processed over 18 months). 3 Guide to Data Protection Practices for ICT Systems (2021) 4 Guide to Data Protection Practices for ICT Systems (2021), page 8 10 Farrer Park Hospital Pte Ltd (c) The marketing department’s Office 365 work email accounts were accessible from the Internet (i.e. web-mail) which taken together with the above factors, exacerbated their vulnerability to unauthorised access. 18 Without prescribing the specific measures that would have been appropriate for the Organisation’s circumstances, stronger security arrangements, policies and/or controls could have included: (a) Implementing enhanced access controls for the marketing department’s web-mail access (e.g. MFA, IP address based white-listing); (b) Implementing policies and/or processes for the marketing department to collect Medical Information via a more secure platform (e.g. a separate webportal); (c) Implementing policies and/or processes for Medical Information to be regularly moved and purged from the marketing department’s Office 365 email accounts, and stored in a more secure system (e.g. a non-Internet facing medical records or customer relationship management system); and/or (d) Implementing policies and/or processes for Medical Information disclosed via the marketing department’s email accounts to be better protected (e.g. password protecting email attachments). 19 For the avoidance of doubt, it is accepted that web-mail may be an appropriate and cost-effective way for organisations to provide their employees with out-of-office email access, and that it may not be necessary for organisations to implement enhanced controls to regulate the use of all types of web-mail accounts. It is incumbent on organisations to assess whether enhanced controls should be implemented to 11 Farrer Park Hospital Pte Ltd regulate the use of web-mail accounts, considering factors such as the volume and sensitivity of the personal data processed using such accounts. 20 In the present case, while MFA was eventually implemented for the marketing department’s Office 365 work email accounts as an enhanced access control measure, this was unfortunately only after the Incident had occurred. Web-mail accounts are exposed to modes of attack that may defeat or circumvent 8-character alphanumeric password protection. Given that the marketing department was routinely processing personal data of a sensitive nature, it was incumbent on the Organisation to implement stronger security arrangements, policies and/or controls in conjunction with its adoption of web-mail. 21 In the premises, the Commission finds that the Organisation breached the Protection Obligation by failing to implement stronger security arrangements, policies and/or controls in respect of the Email Accounts. Risks arising from Email Auto-Forwarding 22 The automatic forwarding of emails to external domains (“Email Auto- Forwarding”) is a known security risk. In March 2018, it was reported that the Office of the Australian Information Commissioner was investigating a data breach incident notified by a member of the Maersk Group involving the auto-forwarding of 50,000 emails sent to 3 employees’ accounts to external parties5. More recently, in a Private Industry Notification dated 25 November 2020, the United States of America’s Federal Bureau of Investigations warned that cyber-criminals have been exploiting autoforwarding rules on web-based email clients to perpetuate business email compromise 5 https://www.zdnet.com/article/oaic-received-31-notifications-in-the-first-three-weeks-of-data-breach-scheme/ 12 Farrer Park Hospital Pte Ltd scams and recommended, amongst other mitigation measures, that Email AutoForwarding be prohibited by default6. 23 Locally, in Singapore Medical Association [2020] SGPDPCS 13, an unauthorised user gained access to an email account and created an email rule to forward emails to an external email address. 137 emails were forwarded without authorisation, resulting in the unauthorised disclosure of the personal data of 68 individuals. The danger of allowing Email Auto Forwarding is clear, but there is an easy fix – organisations can simply disable this function and ensure that it remains disabled. 24 In the present case, the Organisation conducted a ‘Business Impact Assessment’ in 2013 on the use of Office 365 to assess the risks involved from the use of corporate email and instant messaging. The Organisation also subsequently conducted regular reviews and assessments of security risks arising from the use of Office 365 within the Organisation. Unfortunately, these steps did not include an assessment of the risks arising from Office 365’s default setting which allowed Email Auto-Forwarding. 25 The Organisation, on its part, stated that it had not specifically examined disabling the default Email Auto-Forwarding feature in Office 365 because there had been no guidelines, standards, or benchmarks at the material time prior to the Incident recommending disabling of or management of risks from default Email AutoForwarding. Neither had it been a common industry practice to do so prior to the Incident. In this regard, it is noted that Microsoft only released specific guidance on 6 https://www.ic3.gov/Media/News/2020/201204.pdf 13 Farrer Park Hospital Pte Ltd restricting or controlling Email Auto-Forwarding in Office 365 around July / August 20207. 26 It is recognised that Email Auto-Forwarding may be a useful function that serves valuable needs in relation to some email accounts. The Protection Obligation requires organisations, as part of their periodic security review, to assess the frequency and manner of use of Email Auto-Forwarding, and to weigh and counter the attendant risks. In particular, it is incumbent on organisations to apply their minds and make their own assessments of the risks and implications of adopting the default settings of “out-ofthe-box” software solutions (see COURTS (Singapore) Pte Ltd [2020] SGPDPC 17 at [14] and DS Human Resource Pte. Ltd. [2019] SGPDPC 16 at [9]). 27 On balance, and on the facts of this case, the Organisation is given the benefit of the doubt that the lack of guidelines, standards or benchmarks at the material time may have affected its assessment of the risks arising from the Office 365 default Email Auto-Forwarding rule. This omission will therefore not be factored in determining the enforcement action to be taken in this case. However, there must be no doubt that failure to make reasonable assessment of the risks from Email Auto-Forwarding within an organisation is breach of the Protection Obligation that would, in future cases, be met with the appropriate enforcement action. The Commissioner’s Preliminary Decision 28 In determining whether to impose a financial penalty on the Organisation pursuant to section 48J(1) of the PDPA, and if so, the amount of such financial penalty, 7 See https://www.vansurksum.com/2020/08/25/microsoft-is-making-changes-related-to-automatic-email- forwarding-for-atp-customers-here-is-what-you-need-to-know/ referencing Microsoft’s MC 218984 published July 2020 and MC220853 published August 2020. See also: https://docs.microsoft.com/en-us/microsoft365/security/office-365-security/external-email-forwarding?view=o365-worldwide 14 Farrer Park Hospital Pte Ltd the factors listed at section 48J(6) of the PDPA were taken into account, as well as the following mitigating factors: Mitigating Factors (a) The Organisation took immediate remedial actions following the Incident; (b) The Organisation cooperated fully with the Commission during the investigations; (c) Prior to the Incident occurring, the Organisation had in place various technical security measures, including current market solutions; and (d) The Organisation had conducted various data protection and cybersecurity training for its employees. 29 The Organisation was notified of the preliminary decision by way of the Commission’s letter dated 20 April 2022 and was invited to make representations on the same. Representations Made by the Organisation 30 On 6 May 2022, the Organisation made the following representations to the Commission seeking a reduction in the amount of the financial penalty to be imposed: (a) The Organisation had voluntarily notified the Commission and affected individuals of the Incident even though it was not legally obliged to do so under the PDPA, at the material time; (b) There was no misuse of the affected personal data; 15 Farrer Park Hospital Pte Ltd (c) The Organisation took prompt remedial actions to contain and mitigate the effects of the Incident, and prevent recurrence; (d) The Incident was the Organisation’s first breach of the PDPA; and (e) The financial penalty which the Commissioner intended to impose was excessive in light of previous Commission decisions for similar or more serious breaches of the PDPA. Representations on voluntary notification and lack of antecedents 31 The Organisation represented that it voluntary notified the Commission of the Incident despite not being legally obliged to do so, as the obligation for organisations to notify the Commission of notifiable data breaches (as defined under s 26B of the PDPA) only came into effect on 1 February 2022. The Organisation’s voluntary notification of the Incident was taken into account when the Commission determined the preliminary financial penalty, and does not merit a further reduction of the same. 32 Likewise, the Organisation’s representations that it had not committed any breaches of the PDPA prior to the Incident are not accepted. The Organisation’s lack of antecedents had already been taken into account in calibrating the preliminary financial penalty. Representations on the lack of misuse of the affected personal data 33 The Organisation represented that its private forensic expert had monitored the Internet and dark web from 25 February 2020 to 24 April 2020 and not found any information or data (including personal data of the affected individuals) relating to the Incident disclosed during that period. The Organisation further stated that it had not received any complaints from any affected individual as of the date of the 16 Farrer Park Hospital Pte Ltd representations in relation to misuse of their personal data. The Organisation therefore represented that no individuals had been harmed or had suffered loss as a result of the Incident. 34 In support of its representations, the Organisation cited the case of Learnaholic Pte Ltd [2019] SGPDPC 31 (“Learnaholic”), in which the Commissioner had taken into account the fact that “while there was actual exfiltration of the Personal Data…there was no evidence of further exploitation, use or disclosure of the Personal Data by the attacker.”8 35 In the case of Learnaholic the main factors taken into account when deciding to reduce the preliminary financial penalty imposed were: (a) A reduction in the total number of affected individuals due to a recalculation of figures; and (b) The benefit of doubt given to Learnaholic as to the period of time the vulnerability in its system existed. 36 The lack of evidence of further exploitation, use or disclosure is not, ipso facto, a factor meriting a reduction of the financial penalty. The Organisation’s representations are not accepted as the lack of an aggravating factor (i.e. subsequent exploitation, use or disclosure of personal data) is not in itself a mitigating factor.9 8 Learnaholic at [34] 9 See Public Prosecutor v AOM [2011] SGHC 29 at [37] and Edwin s/o Suse Nathen v Public Prosecutor [2013] SGHC 194 at [24] for the equivalent positions in the criminal sentencing domain. 17 Farrer Park Hospital Pte Ltd Representations on the prompt remedial actions taken by the Organisation 37 The Organisation represented that the Commission had not taken into consideration the immediate nature of the remedial action taken to contain the Incident, as well as the success of the immediate post-Incident remediation and recovery efforts. The Organisation further stated that it had not suffered any breaches of the same nature since the Incident, which was proof of the effectiveness of its remedial actions. 38 The Organisation’s prompt remedial actions were already taken into account in determining the preliminary financial penalty. However, this is weighed against the lengthy time period during which the Email Auto-Forwarding took place (March 2018 – October 2019) and long delay in detecting the breach in the first place. Representations on previous Commission decisions 39 The Organisation cited two previous Commission decisions in support of its representations that the intended financial penalty was excessive for similar or more serious breaches of the PDPA. These two cases are The National Kidney Foundation [2021] SGPDPC 10 (“NKF”) and Singapore Medical Association [2020] SGPDPCS 13 (“SMA”). NKF 40 The breach in NKF concerned a hacker who had gained access to the work email account of one of NKF’s employees, thereby gaining access to 23,145 emails containing the personal data of approximately 500 individuals, including patients, employees, and third parties. The Organisation submitted that both cases were similar in the following areas: 18 Farrer Park Hospital Pte Ltd (a) Types of personal data involved (i.e. sensitive medical information); (b) Similar root causes and nature of the incidents; (c) Failure by the organisations to implement 2FA/MFA for web-mail access at the time of the incidents; 41 (d) Increased data protection awareness as remedial measures; and (e) Mitigating factors. The Organisation distinguished NKF and submitted that a lower financial penalty was justified in this case for the following reasons: (a) The Incident was less egregious than NKF because NKF involved: (i) an additional category of sensitive personal data (bank account information), apart from just medical information; and (ii) the hacker synchronising and downloading contents of the compromised email account; while no such synchronising or further use of the compromised email accounts was detected in the Incident; (b) The Organisation had carried out far more substantial and comprehensive remedial measures than NKF; and (c) The number of individuals affected by the Incident was not significantly higher than the number of individuals affected by the NKF incident. 42 The Organisation’s representations are not accepted for the following reasons: 19 Farrer Park Hospital Pte Ltd (a) In NKF only 8 patients’ medical information was compromised, as opposed to the disclosure of 1,923 individuals’ medical information due to the Incident. The breach in the Incident was therefore of a much larger magnitude. (b) The length of time that the breach went undetected was much longer in the Incident – the first email account was compromised in early 2018 and went undetected by the Organisation until October 2019, which was more than a year. This is much longer than the time it took for detection of the breach in NKF, where the hacker obtained access around 14 May 2020 and NKF discovered the breach on 17 May 2020. (c) The number of individuals affected by the Incident is more than 7 times higher (500 in NKF as opposed to 3,539 in the Incident). The two incidents thus cannot be considered in the same bracket of egregiousness. SMA 43 The breach in SMA concerned unauthorised access to an email account by brute force attack, and the subsequent forwarding of 137 emails containing the personal data of 68 individuals to an external email address. The Organisation submitted that both cases were similar in the following areas: 44 (a) Types of personal data involved; and (b) Similar root causes and nature of the incidents. The Organisation distinguished SMA and submitted that a lower financial penalty was justified because the Organisation had implemented more comprehensive security measures than SMA. In particular, the Organisation highlighted its own 20 Farrer Park Hospital Pte Ltd periodic changes of email account passwords and limit of the number of failed login attempts, in contrast with SMA which did not implement these measures. 45 The Organisation’s representations are not accepted as the volume and sensitivity of personal data affected in the Incident was much higher than in SMA: (a) The number of affected individuals in the Incident was 3,539; many times higher than the 68 affected individuals in SMA. (b) The following categories of sensitive information were disclosed in the Incident but not in SMA: passport details, photographs, contact numbers, and notably, specific medical information. As a hospital, the Organisation must be held to a higher standard with regard to safeguarding medical information. 46 Notwithstanding the foregoing, the Commission notes that the Organisation voluntarily accepted the Commission’s findings in the preliminary decision, that it had failed to comply with the Protection Obligation and explicitly indicated what it would not seek to challenge these findings. The Organisation’s voluntary acceptance of liability (even at this late stage) is accepted to have some mitigating weight, meriting a small reduction in the financial penalty. Had the Organisation accepted responsibility for the Incident at an earlier stage of the investigation, this may have merited a larger discount. An organisation that voluntarily accepts responsibility for its non-compliance with the PDPA is an organisation that demonstrates its commitment to the Accountability Obligation and shows that it can be responsible for the personal data in its possession or under its control.10 47 Having considered all the relevant factors of this case, the Commissioner hereby requires the Organisation to pay a financial penalty of $58,000 within 30 days 10 S 11(2) of the PDPA 21 Farrer Park Hospital Pte Ltd from the date of the relevant notice accompanying this decision, failing which interest at the rate specified in the Rules of Court in respect of judgment debts shall accrue and be payable on the outstanding amount of such financial penalty until the financial penalty is paid in full. 48 No further directions are necessary on account of the remedial measures already taken by the Organisation. YEONG ZEE KIN DEPUTY COMMISSIONER FOR COMMISSIONER FOR PERSONAL DATA PROTECTION 22 ",Financial Penalty,0022595df88e4b744c91519d483b5cc7416a2511,"[""tags"",""decision"",""pdf-url"",""description"",""date"",""timestamp"",""url"",""title"",""nature"",""pdf-content""]" 2023-10-01T11:02:10+08:00,fbd32491db44d3d0c97aa12a99cefd61ec954264,19,19,1,1016,QCP Capital was found not in breach of the PDPA in relation to an incident whereby threat actor(s) exfiltrated personal data via unauthorised access to an employee's account.,"[""Protection"", ""Not in Breach"", ""Finance and Insurance""]",2022-10-25,https://www.pdpc.gov.sg/-/media/Files/PDPC/PDF-Files/Commissions-Decisions/Decision---QCP-Capital-Pte-Ltd---16092022-(002).pdf,Protection,No Breach of the Protection Obligation by QCP Capital,https://www.pdpc.gov.sg/all-commissions-decisions/2022/10/no-breach-of-the-protection-obligation-by-qcp-capital,2022-10-25,"PERSONAL DATA PROTECTION COMMISSION [2022] SGPDPCS 16 Case No. DP-2108-B8816 In the matter of an investigation under section 50(1) of the Personal Data Protection Act 2012 And QCP Capital Pte Ltd SUMMARY OF THE DECISION 1. On 30 August 2021, QCP Capital Pte Ltd (the “Organisation”) notified the Personal Data Protection Commission (the “Commission”) of a personal data breach that had occurred through an unauthorised access to employee accounts and exfiltration of customer personal data (the “Incident”). 2. As a result of the Incident, the personal data of 675 individuals was exfiltrated. The personal data affected includes name, NRIC number, date of birth, address, passport scan, passport number, photograph, email address, phone number, Telegram and WeChat ID, whitelisted address and trading records (which included the account balances, buy/sell/settlement activities). Page 1 of 3 3. The Organisation engaged an external cybersecurity company, Blackpanda Pte Ltd, to investigate the Incident. Its investigations found that the threat actor(s) had accessed two accounts, belonging to one employee, to gain unauthorised access to the Organisation systems and subsequently exfiltrated of personal data. 4. Investigations revealed that the Organisation had provided and made reasonable security arrangements to protect personal data in its possession and/or control in relation to the Incident. The Organisation also had an internal monitoring system in place which allowed the Organisation to detect, escalate the anomalous transaction, flag and suspend the trading account affected. 5. Following the Incident, the Organisation took prompt and extensive remedial action to mitigate the effects of the Incident and enhance the overall robustness of its security measures. This included notifying the affected individuals, layering access controls and introducing mandatory hardware key access authentication. 6. In view of the above, the Deputy Commissioner for Personal Data Protection is satisfied that the Organisation was in compliance with its Protection Obligation under section 24 of the PDPA and cannot be held liable for the unauthorised access by the threat actor(s) involved. No enforcement action therefore needs to be taken in relation to the Incident. Page 2 of 3 The following provision(s) of the Personal Data Protection Act 2012 had been cited in the above summary: Protection of personal data 24. An organisation shall protect personal data in its possession or under its control by making reasonable security arrangements to prevent – (a) unauthorised access, collection, use, disclosure, copying, modification, disposal or similar risks; and (b) the loss of any storage medium or device on which personal data is stored. Page 3 of 3 ",Not in Breach,b38af202b30c4ef6f100bb2255281e89e63fdcc6,"[""tags"",""decision"",""pdf-url"",""description"",""date"",""timestamp"",""url"",""title"",""nature"",""pdf-content""]" 2023-10-01T11:02:10+08:00,fbd32491db44d3d0c97aa12a99cefd61ec954264,20,20,1,1016,"A financial penalty of $26,000 was imposed on Cognita Asia Holdings for failing to put in place reasonable security arrangements to protect the personal data in its possession from a ransomware attack.","[""Protection"", ""Financial Penalty"", ""Education"", ""Ransomware"", ""Schools""]",2022-10-25,https://www.pdpc.gov.sg/-/media/Files/PDPC/PDF-Files/Commissions-Decisions/Decision---Cognita-Asia-Holdings-Pte-Ltd---09062022.pdf,Protection,Breach of the Protection Obligation by Cognita Asia Holdings,https://www.pdpc.gov.sg/all-commissions-decisions/2022/10/breach-of-the-protection-obligation-by-cognita-asia-holdings,2022-10-25,"PERSONAL DATA PROTECTION COMMISSION [2022] SGPDPCS 14 Case No. DP-2106-B8484 In the matter of an investigation under section 50(1) of the Personal Data Protection Act 2012 And Cognita Asia Holdings Pte Ltd SUMMARY OF THE DECISION 1. On 16 June 2021, Cognita Asia Holdings Pte Ltd (the ""Organisation"") notified the Personal Data Protection Commission (the “Commission”) of a ransomware attack on 13 June 2021. The ransomware incident (the ""Incident"") affected the servers of three schools run by the Organisation. 2. The ransomware encrypted the personal data of 1,260 individuals, of which 1,195 are students. The personal data included copies of identification/passport page, salaries of the affected employees and the bank account details necessary for the crediting of salaries. Page 1 of 5 3. The Organisation’s internal investigations found that the threat actor gained initial entry to one of the school's network in April 2021 through a VPN session. The VPN logs showed no brute-force entry attempts, suggesting the use of compromised administrator account credentials. Investigations disclosed that between 8 and 12 June 2021, the threat actor gained broad network access and deployed the encrypting ransomware. 4. The Organisation requested that this matter proceed via the Expedited Decision Breach Procedure, which the Commission acceded to. To this end, the Organisation voluntarily and unequivocally admitted to the facts set out in this decision. It also admitted to a breach of section 24 of the Personal Data Protection Act (the ""PDPA""), also referred to as the Protection Obligation. 5. At the time of the Incident, even though the Organisation employed VPN, the Organisation’s existing configuration of VPN required merely a username and password for authentication. However, the personal data collected and processed by the Organisation included copies of the photographic identification documents of students as well as salary and bank account information of employees. In view of the nature of personal data that it holds, the Organisation needed a higher level of security and stronger access control for its administrator accounts, such as multifactor authentication for VPN connection to its administrator accounts to protect such personal data. Page 2 of 5 6. The Organisation also failed to have reasonable password policies or ensure compliance with their existing password policies. The Organisation did not enforce their password policies in the following areas: (i) Although the Organisation's password policy specified a minimum requirement of 10 characters, in practice the requirement that was enforced by their IT systems was only 8 characters; and (ii) Its password policy of requiring the default password to be changed after the first usage was not enforced. 7. The Commission's Handbook on ""How to Guard Against Common Types of Data Breaches"", which is complemented by the ""Checklists to Guard Against Common Type of Data Breaches"", has identified poor management of accounts and passwords as one of the five common causes and types of data breaches. Organisations must adopt, implement, and enforce a strong password policy as a necessary measure of data protection. 8. Finally, the Organisation also failed to ensure that personal data protection training was conducted for its staff. In this regard, the Commission wishes to reiterate that staff training in personal data protection is an important and necessary component of the Protection Obligation of an organisation. 9. In light of the above, the Organisation is found to have breached section 24 of the PDPA. Page 3 of 5 10. The Commission acknowledged that, the Organisation informed the relevant stakeholders of the Incident and implemented real time threat monitoring and Deep and Dark Web monitoring for potentially exposed personal data. 11. The Organisation also undertook remedial actions to mitigate the effects of the Incident and improve the robustness of its security measures. This included the engagement of a cybersecurity expert to investigate the cause of the Incident and working together with the said expert to enact a Remediation Plan. 12. The Remediation Plan included measures such as, enforcing multi-factor authentication of all staff accounts, enhancing the password requirements for administrator accounts, and increasing the frequency of security reviews and cyber security trainings for its staff. 13. The Organisation also conducted security awareness webinars and offered a 12 months’ personal identity monitoring services to all the staff and parents (who can sign up on behalf of the affected students) of these three schools. 14. The Commission’s decision to require payment of a financial penalty, and on the quantum of the penalty, took into account sections 48J(1) and 48J(6) of the PDPA, and all the relevant circumstances of the case. This included the Organisation's admission of breach of the Protection Obligation, which the Commission considers Page 4 of 5 is a significant mitigating factor. Having considered all the facts of this case, the Commissioner hereby requires the Organisation to pay a financial penalty of S$26,000. 15. The Organisation must make payment of the financial penalty within 30 days from the date of the notice accompanying this decision, failing which interest at the rate specified in the Rules of Court in respect of judgment debts shall accrue and be payable on the outstanding amount of such financial penalty until the financial penalty is paid in full. 16. In view of the remedial actions taken by the Organisation, the Commission will not issue any directions under section 48I of the PDPA. The following are the provision of the Personal Data Protection Act 2012 cited in the above summary: Protection of personal data 24. An organisation must protect personal data in its possession or under its control by making reasonable security arrangements to prevent – (a) unauthorised access, collection, use, disclosure, copying, modification or disposal or similar risks; and (b) the loss of any storage medium or device on which personal data is stored. Page 5 of 5 ",Financial Penalty,2bb79bfdd23b06a8855ff98de1a352eac57e3ebd,"[""tags"",""decision"",""pdf-url"",""description"",""date"",""timestamp"",""url"",""title"",""nature"",""pdf-content""]" 2023-10-01T11:02:10+08:00,fbd32491db44d3d0c97aa12a99cefd61ec954264,21,21,1,1016,"A financial penalty of $60,000 was imposed on MyRepublic for failing to put in place reasonable security arrangements to protect the personal data in its possession.","[""Protection"", ""Financial Penalty"", ""Information and Communications""]",2022-09-15,https://www.pdpc.gov.sg/-/media/Files/PDPC/PDF-Files/Commissions-Decisions/Decision---MyRepublic-Ltd---05082022.pdf,Protection,Breach of the Protection Obligation by MyRepublic,https://www.pdpc.gov.sg/all-commissions-decisions/2022/09/breach-of-the-protection-obligation-by-myrepublic,2022-09-15,"PERSONAL DATA PROTECTION COMMISSION [2022] SGPDPC 5 Case No. DP-2108-B8814 In the matter of an investigation under section 50(1) of the Personal Data Protection Act 2012 And MyRepublic Limited … Organisation DECISION Page 1 of 11 MyRepublic Limited Lew Chuen Hong, Commissioner — Case No. DP-2108-B8814 5 August 2022 Introduction 1 On 29 August 2021, the Personal Data Protection Commission (“the Commission”) received information that MyRepublic Limited (“the Organisation”) had been the subject of a cyber incident. On 1 September 2021, the Organisation informed the Commission that a threat actor had exfiltrated and deleted customers’ personal data from its IT systems (the “Incident”). 2 The Organisation requested for the investigation to be handled under the Commission’s Expedited Breach Decision procedure. In this regard, the Organisation voluntarily provided and admitted to the facts set out below, and admitted that it had failed to implement reasonable security arrangements to protect the personal data accessed and exfiltrated in the Incident in breach of section 24 of the Personal Data Protection Act 2012 (“PDPA”). Facts of the Case 3 The Organisation is incorporated in Singapore, and is a telecommunications operator that holds a Facilities-Based Operations licence (“FBO Licence”) under Section 5 of the Telecommunications Act 1999. 4 At the time of the Incident, the Organisation accepted customer orders for mobile services through its Mobile Order Portal (“Portal”). The Organisation’s customers who applied for mobile services would submit their customer identity verification and number portability documents (the “KYC documents”) through the Portal, and the Portal would store the KYC documents in a bucket (the “Bucket”) on cloud-storage procured from Amazon Web Services (“AWS”). Page 2 of 11 5 While the Bucket was publicly accessible, its access was restricted through the use of an access key (the “Access Key”) in the Amazon Identity and Access Management feature. The Access Key could only be used to access the Bucket and no other AWS accounts, systems or bucket used by the Organisation. The Access Key was stored in the source code of the Portal to facilitate the transfer of the KYC documents submitted through the Portal, to the Bucket. 6 On 29 August 2021 (SGT), the Organisation became aware that an external actor had accessed and exfiltrated the KYC documents submitted by customers applying for mobile services. The Organisation received an email from the external actor threatening to publish the downloaded customer data unless a ransom was paid. 7 Following the Incident, the Organisation engaged an IT forensic investigator (among others) to assist in its incident response. Investigations revealed that the external actor had utilised the Access Key to access the Bucket. Fortunately, the compromised Access Key could not be used by the external actor to access the Organisation’s other AWS accounts, systems or buckets. However, an unusually large volume of data had been downloaded from the Bucket before it was deleted. 8 While the Organisation was unable to determine with certainty how the external actor had obtained the Access Key, the Organisation determined that the external actor had likely obtained the Access Key through two vulnerabilities identified within the Portal, namely: (a) The disclosure of the Access Key in the Portal’s functionality which displayed technical information; and (b) The disclosure of the Access Key in the Portal’s source code repository which was available to all the Organisation’s developers, one of whom may have inadvertently disclosed the Access Key. Page 3 of 11 9 The personal data of 79,388 of the Organisation’s customers was accessed and exfiltrated in the Incident, comprising the following: (a) For 75,026 Singapore citizens and permanent residents: Scanned copies of both sides of NRIC and work pass cards, which included the customer’s full name, address, date of birth, gender, race, place of birth, full NRIC number, photograph, thumbprint, date of issuance of card, (for Employment Passes only) employer and nationality, and (for Dependant’s Passes only) nationality; (b) For 4,362 foreigners: Scanned copies of residential address documents such as utility bill, tenancy agreement or insurance policy, which included the customer’s name, address and other information; and (c) For 3,631 customers porting an existing mobile service: porting form which included the customer’s full name and mobile phone number. (collectively, the “Customer Data”). Remedial actions 10 Following the Incident, as part of remedial actions, the Organisation: (a) Revoked the Access Key and issued a replacement key for the Bucket; (b) Removed environment configuration files from the Organisation’s Portal that exposed the Access Key; (c) Reviewed activities across all accounts and buckets to ensure that the compromise was isolated to a single bucket; (d) Restricted access to buckets to specific IP addresses through a block- all-with exception policy; Page 4 of 11 (e) Enabled version control on buckets that were not previously controlled/managed; (f) Reviewed to ensure all buckets are private and in line with AWS’ best practices; (g) Reviewed to ensure all access keys are rotated; (h) Consolidated all AWS accounts with central monitoring enabled; (i) Cleaned up DNS registry across the Organisation’s IT landscape; (j) Issued a notification to the affected customers, recommending actions to minimise the risks of identify fraud and social engineering, and offering the affected customers six months of complimentary credit monitoring services; (k) Conducted dark web monitoring from 3 September 2021 to 3 October 2021 to verify whether the exfiltrated data have been published; and (l) Commissioned the development of a programme of security improvements for the Organisation’s systems in order to reduce the risk of security incidents. Findings and Basis for Determination Whether the Organisation had contravened the Protection Obligation 11 Section 24 of the Personal Data Protection Act 2012 (“PDPA”) requires an organisation to protect personal data in its possession or under its control by making reasonable security arrangements to prevent unauthorised access, collection, use, disclosure, copying, modification, disposal or similar risks (the “Protection Obligation”). The Organisation is required under the Protection Obligation to implement reasonable security arrangements to prevent the risk of unauthorised disclosure of the Customer Data, notwithstanding that the data was hosted on a Page 5 of 11 vendor’s cloud service. This is because the Organisation retains control over such data. In Commeasure Pte Ltd [2021] SGPDPC 11 (“Commeasure”) at [11], the Commission found that even though a vendor was responsible for the security of the cloud infrastructure that it provided to the organisation, the organisation bore ultimate responsibility under the Protection Obligation for making reasonable security arrangements to protect all the customers’ data under its control. 12 The reasonableness of the Organisation’s security arrangements to protect the Customer Data would be assessed having regard to the volume and sensitivity of such personal data. As stated in the Commission’s Advisory Guidelines on Key Concepts in the Personal Data Protection Act (revised 1 October 2021) (“Advisory Guidelines”) at [17.3], an organisation should design and organise its security arrangements to fit the nature of the personal data held by the organisation and the possible harm that might result from a security breach, and implement robust policies and procedures for ensuring appropriate levels of security for personal data of varying levels of sensitivity. 13 In the course of its business, the Organisation collected and retained copies of its customers’ KYC documents such as NRICs and work passes, which contained their Customer Data, in compliance with its FBO Licence.1 At the time of the Incident, the Organisation had in its control a high volume of sensitive personal data: (a) High volume of Customer Data: At the time of the Incident, the Organisation had in its control the Customer Data of almost 80,000 individuals. (b) Sensitivity of Customer Data: The Customer Data included the customers’ full NRIC numbers, photographs, thumbprints, and dates of issuance of their NRIC cards. The sensitivity of such information is heightened 1 Under its FBO Licence, the Organisation is required to (i) maintain a register containing records of its customers, including the customers’ identity number such as NRIC number, (ii) make and keep a photocopy of its customers’ NRIC, passport or employment pass as evidence of the customers’ identity, and (iii) keep the register of the customers for at least 12 months from the date of termination of its services to the customers (among others). Page 6 of 11 and there is an increased risk, for example, of identity theft, as the information could enable access to other services provided by the Government. 14 Accordingly, the Organisation should have implemented stronger security measures to protect the Customer Data. 15 For the reasons set out below, the Organisation failed to put in place such reasonable security arrangements to protect the Customer Data and was determined to be in breach of the Protection Obligation (as also admitted by the Organisation). In particular, the Organisation failed to implement sufficiently robust processes to manage the Access Key, and also failed to implement reasonable security controls for its AWS environment. Failure to implement sufficiently robust processes to manage Access Key 16 The Organisation’s Protection Obligation required it to protect the Access Key, which allowed access to the Customer Data in the Bucket. As stated in Commeasure at [12], AWS has, in its “Reference Guide – AWS security credentials” (“AWS Reference Guide”), advised users to protect the access keys as “anyone who has the access keys for your AWS account root user has unrestricted access to all resources in your AWS account”.2 17 However, the Organisation failed to implement sufficiently robust processes to protect the Access Key. 18 The Organisation informed the Commission that the Access Key could be disclosed through the Portal’s functionality to display technical information, at https://mobile.myrepublic.com.sg/php-info. The functionality, known as “PHP Info”, is a standard function of the PHP programming environment and helps programmers to understand the configuration of the environment. The “PHP Info” function is invoked https://docs.aws.amazon.com/general/latest/gr/aws-access-keys-best-practices.html – see “Best practices for managing AWS access keys” (last accessed on 5 August 2022). Page 7 of 11 2 by executing a PHP script file. Thereafter, if the php-info URL is accessed, the browser will display the Portal’s operating system environment variable values. These values included the Access Key, which was used by the Portal to access and transfer documents submitted by customers through the Portal to the Bucket. This was a significant vulnerability as anyone who knew or could guess the php-info URL could obtain the Access Key and use it to access the Customer Data in the Bucket. The Organisation also determined that this was the most likely way in which the external actor had obtained the Access Key. The Organisation should not have left the Access Key publicly accessible through the php-info URL. Instead, the Organisation could have disabled the “PHP Info” function or moved the Access Key from the Portal’s system environment variables to configuration files available only to authorised parties. 19 Further, the Organisation informed the Commission that the Access Key was embedded in the Portal’s source code available to all the Organisation’s developers via the source code repository. This was another way through which the external actor could have obtained the Access Key or one of the developers with access could have inadvertently disclosed it. The Commission has held in Commeasure at [12] that embedding AWS access keys into the source code of applications poses a clear security risk. In the AWS Reference Guide, AWS has likewise cautioned users not to “embed access keys directly into code”. The Organisation could have stored the Access Key in a file that is separate from the source code and secured with separate access controls, or it could have utilised third party solutions for the management of access keys. 20 In addition, the Access Key was captured in the clear in mobile order application log files made available to employees, including external developers and engineers, who did not require such information for their functions. If the Organisation wanted to store credentials such as the Access Key in its log files (e.g. for development purposes), it should have implemented reasonable security measures such as a log file redaction mechanism to prevent disclosure of such credentials. Page 8 of 11 21 In view of the above, the Organisation was found in breach of the Protection Obligation for its failure to implement sufficiently robust processes to manage the Access Key. Failure to implement reasonable security controls for AWS environment 22 Apart from the Organisation’s failures in its management of the Access Key, the Organisation also failed to implement reasonable security controls for its AWS environment. 23 The Commission had stated in the Guide to Data Protection by Design for ICT Systems (2021) (“Guide”) that as a basic practice, organisations should “[e]nsure that files containing personal data are not accidentally made available on a website or through a web application”, and “avoid storing personal data in public folders” (at page 20). In the “Amazon Simple Storage Service – User Guide”, AWS has similarly advised its users that “[u]nless [they] explicitly require anyone on the internet to be able to read or write to [their] S3 bucket, [they] should ensure that [their] S3 bucket is not public”.3 24 However, as stated at [5] above, the Bucket was publicly accessible. This significantly increased the risk profile of the Bucket as external actors could find the Bucket and thereafter access, exfiltrate and delete the Customer Data in the Bucket, which is what occurred in the Incident. Given the high volume and sensitivity of the Customer Data stored in the Bucket, the Bucket should not have been made publicly available. This is especially if the Bucket was meant to interact only with the Portal for customers to upload KYC documents for retrieval by the Organisation’s back-office systems. 25 The Commission had stated in the Guide that organisations should put in place ICT controls to manage data protection risks, including setting appropriate access https://docs.aws.amazon.com/AmazonS3/latest/userguide/security-best-practices.html – see “Amazon S3 Preventative Security Best Practices” (last accessed on 5 August 2022). Page 9 of 11 3 control rules, access rights, and restrictions for specific user roles (at pages 9 and 15). Access to the Bucket should therefore have been restricted to only authorised applications or users. In this case, the Organisation sought to restrict access to the Bucket through the use of the Access Key, but it turned out to be ineffective because of the Organisation's handling and inadvertent disclosure of the Access Key, as stated above. The Organisation could also have considered layering its defences, and could have supplemented the Access Key with a “block-all but” exception policy that allows only specific IP addresses to access the Bucket, as implemented by the Organisation after the Incident. 26 Accordingly, the Organisation was found to be in breach of the Protection Obligation for failing to implement reasonable security controls for its AWS environment. The Commissioner’s Directions 27 In determining whether to impose a financial penalty on the Organisation pursuant to section 48J(1) of the PDPA, and the amount of any such financial penalty, the matters set out at section 48J(1) and the factors listed at section 48J(6) of the PDPA were taken into account, as well as the following mitigating factors: Mitigating Factors (a) The Organisation took prompt and effective remedial actions, including notifying the affected individuals; and (b) 28 The Organisation was cooperative during investigations. The Commission also considered the Organisation’s voluntary acceptance of liability for the Incident. Page 10 of 11 29 Having considered all the relevant factors of this case, the Commissioner hereby requires the Organisation to pay a financial penalty of $60,000 within 30 days from the date of the relevant notice accompanying this decision, failing which interest at the rate specified in the Rules of Court in respect of judgment debts shall accrue and be payable on the outstanding amount of such financial penalty until the financial penalty is paid in full. 30 No further directions are necessary on account of the remedial measures already taken by the Organisation. YEONG ZEE KIN DEPUTY COMMISSIONER FOR COMMISSIONER FOR PERSONAL DATA PROTECTION Page 11 of 11 ",Financial Penalty,281b38e59a842f8bbcce33f312e6d5fdca027752,"[""tags"",""decision"",""pdf-url"",""description"",""date"",""timestamp"",""url"",""title"",""nature"",""pdf-content""]" 2023-10-01T11:02:10+08:00,fbd32491db44d3d0c97aa12a99cefd61ec954264,22,22,1,1016,"Directions were issued to Budgetcars to put in place appropriate contractual provisions, conduct a security audit of its technical and administrative arrangements for the security and maintenance of its website and rectify any security gaps identified in the audit report. This is pursuant to a data breach incident where personal data could be accessed by changing a few digits of the tracking ID.","[""Protection"", ""Directions"", ""Transport and Storage""]",2022-08-11,https://www.pdpc.gov.sg/-/media/Files/PDPC/PDF-Files/Commissions-Decisions/Decision---Budgetcars-Pte-Ltd---06072022.pdf,Protection,Breach of the Protection Obligation by Budgetcars,https://www.pdpc.gov.sg/all-commissions-decisions/2022/07/breach-of-the-protection-obligation-by-budgetcars,2022-08-11,"PERSONAL DATA PROTECTION COMMISSION [2022] SGPDPCS 13 Case No. DP-2108-B8798 In the matter of an investigation under section 50(1) of the Personal Data Protection Act 2012 And Budgetcars Pte. Ltd. SUMMARY OF THE DECISION 1. On 25 August 2021, the Personal Data Protection Commission (the “Commission”) received a complaint that the delivery tracking function (the “Tracking Function Page”) on the website of Budgetcars Pte Ltd (the “Organisation”) could be used to gain access to the personal data belonging to another individual. By changing a few digits of a Tracking ID, the complainant could access the personal data of another individual (the “Incident”). 2. The Organisation is a logistics company delivering parcels to customers (“Customers”) on behalf of retailers (“Retailers”). 3. The personal data of 44,357 individuals had been at risk of unauthorised access. The datasets comprised name, address, contact number and photographs of their signatures. 4. The Tracking Function Page was set up in December 2020 to allow Retailers and Customers to (i) keep track of the delivery status of their parcels; and (ii) confirm the identity of individuals to collect parcels on their behalf (where applicable). The Tracking IDs were generated by Retailers and comprised either sequential or nonsequential numbers. Although generated by Retailers, the Organisation adopted the Tracking IDs for use on its own Tracking Function Page that allowed their customers to track their deliveries, which would disclose personal data listed above. The Protection Obligation therefore required the Organisation to ensure that there were reasonable access controls in its use of the Tracking IDs for giving access to an individual’s personal data. 5. The risk of unauthorised access to personal data from altering numerical references, both sequential and non-sequential, have featured in the published decisions of the Commission in Re Fu Kwee Kitchen Catering Services [2016] SGPDPC 14, and more recently, in Re Ninja Logistics Pte. Ltd. [2019] SGPDPC 39. Insecure direct object reference has long been a well-known security risk to personal data. The Organisation failed to have reasonable access control to the affected individuals’ personal data when it simply adopted Tracking IDs generated by the Retailers without factoring in this risk. 6. The Organisation also admitted that it did not have in place a process to protect personal data through proper safeguards by archiving personal data relating to a completed delivery order after a reasonable period of time has lapsed. To reduce the risk of access to personal data through frontend applications, they should be removed and archived within a reasonable time. The Organisation’s failure to do so resulted in more personal data at risk in the Incident than should have been the case. 7. In the circumstances, the Organisation is found to be in breach of section 24 of the PDPA. 8. Upon being notified by the Commission of the Incident, the Organisation took the following remedial measures after the Incident: a. Removed all personal data from the Tracking Function Page; b. Engaged its IT solutions provider to re-examine management of the Tracking Function Page; c. Post-delivery expiry of Tracking ID after 14 days; and d. Implemented checks to prevent sequential Tracking IDs from being uploaded onto the Tracking Function Page. 9. The Commission accepted the Organisation’s request for this matter to be handled under the Commission’s expedited breach decision procedure. This meant that the Organisation voluntarily provided and unequivocally admitted to the facts set out in this decision. The Organisation also admitted that it was in breach of section 24 of the Personal Data Protection Act (the “PDPA”). 10. In Re Ninja Logistics Pte. Ltd. cited above, the organisation had been aware of the risk from manipulation of Tracking IDs. However, a counter-measure which the organisation initially introduced was abandoned due to operational issues and was not replaced. This resulted in a significantly larger dataset (>1.2 million) that was exposed to the risk of unauthorised access over a period of close to 2 years. In comparison, the number of affected individuals in the present case was lower as the Organisation was only handling deliveries for a few Retailers at the time of the Incident. 11. Having considered the circumstances set out above and the factors listed in section 48J(6) of the PDPA, including (i) the Organisation’s upfront voluntary admission of liability; and (ii) the prompt remedial action undertaken by the Organisation, the Commission considered that it would be appropriate not to require the payment of a financial penalty but to direct the Organisation to do the following: a. To put in place the appropriate contractual provisions to set out the obligations and responsibilities of both the data controller and data intermediary to protect the Organisation’s personal data, and the parties’ respective roles in protecting the personal data; b. To engage qualified security service provider to conduct a thorough security audit of its technical and administrative arrangements for the security and maintenance of its website that contains personal data in the Organisation’s possession or control; c. Provide the full security audit report to the Commission, no later than 60 days from the date of the issue of this direction; d. Rectify any security gaps identified in the security audit report, review and update its personal data protection policies as applicable within 60 days from the date the security audit report is provided; and e. Inform the Commission within 1 week of completion of rectification and implementation in response to the security audit report. The following is the provision of the Personal Data Protection Act 2012 cited in the above summary: Protection of personal data 24. An organisation shall protect personal data in its possession or under its control by making reasonable security arrangements to prevent – (a) unauthorised access, collection, use, disclosure, copying, modification, disposal or similar risks; and (b) the loss of any storage medium or device on which personal data is stored. ",Directions,f58b11a86b70faf2534d0dbe08ee7f22ddbeaeb9,"[""tags"",""decision"",""pdf-url"",""description"",""date"",""timestamp"",""url"",""title"",""nature"",""pdf-content""]" 2023-10-01T11:02:10+08:00,fbd32491db44d3d0c97aa12a99cefd61ec954264,23,23,1,1016,Directions were issued to Crawfort to conduct a security audit of its technical and administrative arrangements for its AWS S3 environment and rectify any security gaps identified in the audit report. This is pursuant to a data breach incident where Crawfort's customer database were offered for sale in the dark web.,"[""Protection"", ""Directions"", ""Finance and Insurance""]",2022-07-14,https://www.pdpc.gov.sg/-/media/Files/PDPC/PDF-Files/Commissions-Decisions/Decision---Crawfort-Pte-Ltd---070622.pdf,Protection,Breach of the Protection Obligation by Crawfort,https://www.pdpc.gov.sg/all-commissions-decisions/2022/07/breach-of-the-protection-obligation-by-crawfort,2022-07-14,"PERSONAL DATA PROTECTION COMMISSION Case No. DP-2106-B8446 In the matter of an investigation under section 50(1) of the Personal Data Protection Act 2012 And Crawfort Pte. Ltd. SUMMARY OF THE DECISION 1. On 9 June 2021, Crawfort Pte. Ltd. (the “Organisation”) notified the Personal Data Protection Commission (the “Commission”) of the sale of the Organisation’s customer data on the dark web (the “Incident”). 2. The personal data of 5,421 customers were affected. The datasets affected comprised NRIC images (front and back), PDF copies of loan contract (containing all the information in the NRIC, age, email address, contact number and loan amount) and PDF copies of income document (payslip, CPF statements or IRAS Notice of Assessment). 1 3. The Organisation engaged external cyber security teams to investigate the Incident. The investigation identified an opened S3 server port in the Organisation’s AWS environment as the cause of the Incident. 4. The Organisation explained that it had opened the S3 server port for one week during a data migration exercise sometime on or about 15 April 2020 for business continuity purposes. On 3 April 2020, the Singapore government had announced that the country will enter into a Circuit Breaker to contain the spread of COVID-19. All non-essential workplaces, including the Organisation, had to be closed from 7 April 2020. In order to continue its business, the Organisation had to pivot its operations so as to allow its staff to work from home and its customers to make loan applications remotely. Within a very short period, the Organisation had to carry out the data migration exercise and as a result, overlooked conducting a risk assessment prior to conducting the data migration exercise. 5. The opened S3 server port connected directly to the S3 server hosting the S3 buckets, which contained the affected personal data. The open remote port enabled attempts to connect to the Organisation’s AWS environment from the internet. Furthermore, the S3 bucket containing the affected personal data was publicly accessible due to a misconfiguration of the S3 bucket. As a result, the threat actor was able to gain access to the publicly accessible S3 bucket during the one-week period. 2 6. The Organisation the following remedial measures after the Incident: a. Reset and reconfigured all whitelisted IPs to AWS server; b. Reset and reconfigured all VPNs; c. Limited the whitelisted IP addresses to its web portal; d. Conducted a penetration test; e. Monitored the dark web to ensure that data was not circulated; f. Engaged independent cyber security consultant to carry out investigation, study the IT infrastructure and propose improvements to their systems; and g. Notified affected individuals. 7. The Commission accepted the Organisation’s request for this matter to be handled under the Commission’s expedited breach decision procedure. This meant that the Organisation had voluntarily provided and unequivocally admitted to the facts set out in this decision. The Organisation also admitted that it was in breach of section 24 of the Personal Data Protection Act (the “PDPA”). 8. The Organisation admitted that it failed to conduct a reasonable risk assessment before carrying out the data migration exercise. There was no access control to the S3 bucket containing the affected personal data during the week-long migration exercise. This, coupled with the open port, allowed the threat actor to gain access to the affected personal data. 3 9. In the circumstances, the Organisation is found to be in breach of section 24 of the PDPA. 10. Having considered the circumstances set out above and the factors listed in section 48J(6) of the PDPA, including (i) the Organisation’s upfront voluntary admission of liability which significantly reduced the time and resources required for investigations; and (ii) the prompt remedial actions undertaken by the Organisation, the Commission considered that it would be most appropriate in lieu of imposing a financial penalty, to direct the Organisation to comply with the following: a. To engage qualified security service provider to conduct a thorough security audit of its technical and administrative arrangements for the security and maintenance of its AWS S3 environment that contains personal data in the Organisation’s possession or control; b. Provide the full security audit report to the Commission, no later than 60 days from the date of the issue of this direction; c. Rectify any security gaps identified in the security audit report, review and update its personal data protection policies as applicable within 60 days from the date the security audit report is provided; and d. Inform the Commission within 1 week of completion of rectification and implementation in response to the security audit report. 4 The following provision(s) of the Personal Data Protection Act 2012 had been cited in the above summary: Protection of personal data 24. An organisation shall protect personal data in its possession or under its control by making reasonable security arrangements to prevent – (a) unauthorised access, collection, use, disclosure, copying, modification, disposal or similar risks; and (b) the loss of any storage medium or device on which personal data is stored. 5 ",Directions,e2755a8249f833e1c234b8532991f2dc6896ee30,"[""tags"",""decision"",""pdf-url"",""description"",""date"",""timestamp"",""url"",""title"",""nature"",""pdf-content""]" 2023-10-01T11:02:10+08:00,fbd32491db44d3d0c97aa12a99cefd61ec954264,24,24,1,1016,"A financial penalty of $10,000 was imposed on Audio House for failing to put in place reasonable security arrangements to protect the personal data in its possession from a ransomware attack.","[""Protection"", ""Financial Penalty"", ""Wholesale and Retail Trade"", ""Ransomware""]",2022-07-14,https://www.pdpc.gov.sg/-/media/Files/PDPC/PDF-Files/Commissions-Decisions/Decision---Audio-House-Marketing-Pte-Ltd---27052022.pdf,Protection,Breach of the Protection Obligation by Audio House,https://www.pdpc.gov.sg/all-commissions-decisions/2022/07/breach-of-the-protection-obligation-by-audio-house,2022-07-14,"PERSONAL DATA PROTECTION COMMISSION Case No. DP-2106-B8421 In the matter of an investigation under section 50(1) of the Personal Data Protection Act 2012 And Audio House Marketing Pte Ltd SUMMARY OF THE DECISION 1. On 1 June 2021, Audio House Marketing Pte Ltd (the “Organisation”) notified the Personal Data Protection Commission (the “Commission”) of a ransomware affecting its customer database (the “Incident”). Approximately 98,000 individuals’ names, addresses, email addresses and telephone numbers, in the nature of contact information, were affected. 2. The Organisation subsequently requested for this matter to be handled under the Commission’s expedited breach decision procedure. This means that the Organisation voluntarily provided and unequivocally admitted to the facts set out in 1 this decision; and admitted that it was in breach of section 24 of the Personal Data Protection Act (the “PDPA”). 3. The Organisation’s internal investigations revealed that PHP files used to develop a web application on the Organisation’s website contained vulnerabilities that allowed the threat actor to carry out a SQL injection attack. The Organisation admitted that it is possible that the vulnerabilities in the PHP files had existed since April 2017, when its website was first launched. Further, even though the Organisation had conducted pre-launch tests prior to the launch of its website, the Organisation admitted that it failed to identify and detect the existing vulnerabilities in the PHP files. 4. SQL injection attacks are well-known vulnerabilities: see “Top Ten” list of the Open Web Application Security Project (OWASP). The Commission has consistently advised organisations to take the necessary precautions to guard against the risk of injection attacks (see para. 15.3 of the Commission’s Guide to Securing Personal Data in Electronic Medium, published on 8 May 2015, and revised on 20 January 2017). We note that apart from conducting functionality testing of features such as the shopping cart and payment on its website, the Organisation did not conduct any vulnerability scanning and assessment that would have provided a reasonable opportunity to discover the vulnerabilities in the PHP files that were eventually exploited in the Incident. 5. Compounding the above, the Organisation also did not conduct reasonable periodic security review. A reasonable periodic security review would include 2 vulnerability scanning and assessments, which would have offered the Organisation the opportunity to detect any vulnerabilities that were not detected during the pre-launch tests, or any vulnerabilities that may have arisen since. 6. Periodic security reviews is also a practice that the Commission has consistently advised organisations to adopt. In our Checklists to Guard against Common Types of Data Breaches, the Commission highlighted that conducting a periodic security review is a basic practice that all organisations ought to embrace. This is also reiterated in para. 6.1(a) of the Commission’s Guide to Securing Personal Data in Electronic Medium where we stated that it was a good practice for organisations to “conduct regular ICT security audits, scans and tests to detect vulnerabilities and non-compliance with organizational standards”, and Table 13(f) of the same Guide where we encouraged organisations to perform web application scanning and source code analysis to help detect common web vulnerabilities, in particular, those identified in the “Top Ten” list of the OWASP, which includes SQL injection attacks. 7. With the use of IT comes the responsibility for data security in IT systems. We urge organisations who may be unable to conduct such security reviews on their own to engage the necessary expertise from the professionals. 8. Having said that, we note that the Organisation’s website was built by a company, which the Organisation’s main IT vendor had engaged on the Organisation’s behalf. The Organisation did not have any contract with the company that developed the website. As a result, the Organisation failed to stipulate clear job 3 specifications or any data protection requirements on the company that developed its website. There was also an absence of any data protection requirements in the Organisation’s contract with its main IT vendor, who it relied upon to manage and maintain its IT systems. The Commission’s published decisions1 have emphasized that organisations engaging IT vendors should – a) stipulate personal data protection requirements on the vendors, b) make clear the job specifications, especially where they include security maintenance and software updates, and, last but not least, c) exercise reasonable oversight over the vendor responsible for the technical capabilities of the organisation so as to offer adequate protection to the types of personal data that may be affected by the engagement of the vendor. In cases where sub-contracting is contemplated, the Organisation should have identified requirements in its main contract that it requires its main IT vendor to impose similar obligations on and exercise adequate oversight over its subcontractor. 9. In light of the above, the Organisation is found to have breached the Protection Obligation under section 24(a) of the PDPA. 10. In deciding the appropriate outcome in this case, the Commission considered the Organisation’s cooperation throughout the investigation, the Organisation’s voluntary admission of breach of the Protection Obligation, and the prompt remediation actions taken. This included disabling the use of its website on the same day of the Incident, reformatting of its webserver, adding security against SQL injections and the implementation of vulnerable assessment and penetration 1 See Jigyasa [2020] SGPDPC 9 and Civil Service Club [2020] SGPDPC 15 4 testing. We note that the Organisation managed to restore all the personal data affected without loss, thereby minimizing any disruptions to its operations. 11. Having considered the circumstances set out above and the factors listed at section 48J(6) of the PDPA, the Deputy Commissioner for Personal Data Protection hereby finds the Organisation in breach and directs the Organisation to pay a financial penalty of S$10,000 within 30 days from the notice accompanying date of this decision, failing which interest at the rate specified in the Rules of Court in respect of judgement debts shall accrue and be payable on the outstanding amount of such financial penalty until the financial penalty is paid in full. 12. In view of the remedial actions taken by the Organisation, no directions under section 48I are necessary. The following is the provision of the Personal Data Protection Act 2012 cited in the above summary: Protection of Personal Data 24. An organisation shall protect personal data in its possession or under its control by making reasonable security arrangements to prevent – (a) unauthorized access, collection, use, disclosure, copying, modification, disposal or similar risks; and (b) the loss of any storage medium or device on which personal data is stored. 5 ",Financial Penalty,2506fbb092f33a10a99d72428ada09a55ade6c6b,"[""tags"",""decision"",""pdf-url"",""description"",""date"",""timestamp"",""url"",""title"",""nature"",""pdf-content""]" 2023-10-01T11:02:10+08:00,fbd32491db44d3d0c97aa12a99cefd61ec954264,25,25,1,1016,"A financial penalty of $12,000 was imposed on Terra Systems for failing to put in place reasonable security arrangements to protect the personal data of individuals in its customer relationship management portal in Re Terra Systems Pte Ltd [2021] SGPDPC 7. An application for reconsideration was filed against the decision in Re Terra Systems Pte Ltd [2021] SGPCPC 7. Upon review and careful consideration of the application, the Commissioner had decided to affirm the finding of the breach of section 24 of the PDPA as set out in the decision and the financial penalty in the Reconsideration Decision.","[""Protection"", ""Financial Penalty"", ""Information and Communications""]",2022-07-14,https://www.pdpc.gov.sg/-/media/Files/PDPC/PDF-Files/Commissions-Decisions/Decision---Terra-Systems-Pte-Ltd----06082021.pdf,Protection,Breach of the Protection Obligation by Terra Systems,https://www.pdpc.gov.sg/all-commissions-decisions/2022/07/breach-of-the-protection-obligation-by-terra-systems,2022-07-14,"PERSONAL DATA PROTECTION COMMISSION [2021] SGPDPC 7 Case No DP-2007-B6670 In the matter of an investigation under section 50(1) of the Personal Data Protection Act 2012 And Terra Systems Pte. Ltd. … Organisation DECISION Terra Systems Pte. Ltd. [2021] SGPDPC 7 Lew Chuen Hong, Commissioner — Case No. DP-2007-B6670 6 August 2021 Introduction 1 On 14 July 2020 and 21 July 2020, a customer relationship management portal (“the Portal”) owned and operated by Terra Systems Pte Ltd (the “Organisation”) containing the personal data of persons served with “Stay-Home Notices” 1 (“SHNs”) was accessed and modified without the Organisation’s authorisation (the “Incident”). 2 On 27 July 2020, the Singapore Police Force notified the Personal Data Protection Commission (“Commission”) of the Incident, and the Commission commenced its own investigations thereafter. Background 3 The Organisation is in the business of providing communication solutions and services, including call centre services, to businesses in Singapore and the region. On 17 June 2020, the Organisation was awarded a government contract to provide call centre services to help verify the whereabouts of persons serving SHNs (“the Call Centre”). 4 To facilitate the operations of the Call Centre, the Immigration and Checkpoints Authority (“ICA”) provided the Organisation with a daily spreadsheet containing the personal data of persons serving SHNs, including their: (a) Name (b) Last 4 digits of NRIC; 1 Legal notices issued under the Infectious Diseases Act (Cap 137) requiring a person to remain at their place of residence or at a Stay-Home Notice Dedicated Facility at all times for a stipulated period 1 (c) Gender; (d) Contact Number; (e) Last Day of SHN; (f) Address where SHN was served; and (g) COVID-19 Test Appointment dates (collectively, the “SHN Data”) 5 The Organisation created the Portal for the purposes of its internal administration of the Call Centre. On account of the movement restrictions in force at the time owing to the COVID19 pandemic, the Portal was designed to be accessible by the Organisation’s staff from home via the Internet. 6 Users in the Organisation were granted different levels of access to the Portal: (a) Directors and managers were assigned unique user IDs and passwords and were able to view all cases in the Portal. (b) Team leaders were also assigned unique user IDs and passwords and were able to view all cases assigned to agents in their teams. (c) Agents (i.e. the persons actually contacting the persons serving SHNs) were temporary staff assigned simple user IDs based on their respective teams (e.g. the user ID “D03” referred to agent number 3 in team D). Agents were also given a common daily password which was shared with them during a morning Zoom briefing by the Organisation’s management. 7 Agents logged in to the Portal were only able to view the cases assigned to them, and type in remarks in a specific “remarks” column after a case had been attended to. At the end of each day, the SHN Data would be submitted to ICA with the agents’ remarks, and all data in the Portal would be purged. 8 On 14 July 2020, crude remarks were found to have been inserted in the remarks field of 3 cases in the Portal. The two agents assigned to deal with those cases and their team leader 2 denied inserting the remarks. The Organisation changed the common password for the day and began informing agents of the new daily common password via Whatsapp instead. The Organisation also implemented a web server logging function to track the actions of users logged in to the Portal. This functionality had not enabled previously. 9 On 21 July 2020, another crude remark was inserted in the remarks field of a case assigned to one of the same agents. The Organisation traced the action to an unauthorized user based on the IP address from which the Portal was accessed and reported the Incident to the police. 10 The perpetrator of the Incident is believed to be a disgruntled ex-employee of the Organisation. On 14 July 2020, the perpetrator is believed to have obtained the daily common password by attending the morning Zoom briefing, after obtaining the login details for the morning Zoom briefing from other employees. On 21 July 2020, the perpetrator is believed to have directly obtained the daily common password from another employee who was unaware that his employment had been terminated. 11 After being notified of the Incident, the Organisation took the following remedial actions on ICA’s instructions: (a) The practice of using common passwords was ceased, and agents were required to adopt unique passwords, (b) Agents were assigned unique user IDs which were different from the generic IDs based on their teams; (c) Two-factor authentication was implemented for all access to the Portal; and (d) Security scanning was performed on the Portal. Findings and Basis for Determination Whether the Organisation had contravened section 24 of the PDPA 12 Section 24 of the PDPA requires an organisation to protect personal data in its possession or under its control by taking reasonable security steps or arrangements to prevent 3 unauthorised access, collection, use, disclosure, copying, modification, disposal or similar risks (“Protection Obligation”). 13 For the reasons set out below, the Organisation is found to have failed to implement reasonable security arrangements to protect the SHN Data from the risk of unauthorised access. Failure to implement reasonable IT access controls 14 Firstly, the Organisation failed to implement reasonable IT access controls to the SHN Data in the Portal. The use of (i) generic user IDs for agents which were known to all or guessable, and (ii) a daily common password for all agents, were poor practices that posed serious security risks. 15 Employing simple user IDs and a common password defeated the purpose of segregating agents’ access to cases in the Portal. Any agent could have accessed another agent’s cases by using that agent’s commonly known or guessable user ID and the common password. While there is only evidence that the perpetrator in this case accessed and modified the SHN Data of 4 persons (based on the distinct cases in the Portal in which crude remarks were inserted), the perpetrator could have accessed the SHN Data of all 125 persons assigned to his former team. 16 The Incident could have been prevented had all agents been assigned unique user IDs and passwords. Failure to implement policies to mitigate risks from using common password 17 Secondly, the Organisation failed to implement adequate policies to mitigate the risks created by the use of a daily common password to access the Portal. Having made the decision to use a common password for access to the Portal, the Organisation attempted to identify the associated risks and adopt suitable policies and practices. Unfortunately, their efforts proved to be inadequate 18 The Organisation clearly recognised some risks associated with use of a common password – this was why they adopted the practice of changing the common password daily. However, it was foreseeable that agents would ask each other for the daily common password, 4 for example, when they had forgotten the password or had missed the morning Zoom briefing. An agent may not have suspected that anything was amiss if someone they believed to be another agent had asked them for the daily password or the login details for the morning Zoom briefing. This risk was exacerbated by the fact that all of the agents were temporary staff and that personnel changes were to be expected. Thus, on both 14 July 2020 and 21 July 2020, the perpetrator is believed to have obtained either the login details for the morning Zoom briefing or the common daily password itself from the Organisation’s employees. 19 If the Organisation had properly appreciated this risk, it could have implemented policies (i) prohibiting agents from disseminating or sharing the daily common password under any circumstances, and (ii) requiring any agents who missed the daily morning Zoom briefings to obtain the daily common passwords directly from their team leaders or managers, who would be better placed to verify the requestor’s employment status. Admittedly, such policies would have been difficult to police. However, they would have at least reduced the risk of disclosure of the common password to unauthorised persons. 20 It is acknowledged that the Organisation was under pressure to operationalise the Call Centre and Portal within a short timeframe to support ICA’s operations in the midst of the COVID-19 pandemic. Even so, its failures to implement reasonable access controls gave rise to the present Incident. The Organisation failed to make reasonable security arrangements to protect the SHN Data from unauthorised access and modification in breach of its obligation under section 24 of the PDPA. The Commissioner’s Decision 21 In determining whether any directions should be imposed on the Organisation under section 48I of the PDPA, and/or whether the Organisation should be required to pay a financial penalty under section 48J of the PDPA, the factors listed at section 48J(6) of the PDPA were considered, with particular emphasis on the following aggravating and mitigating factors: Aggravating Factor (a) The SHN Data was sensitive in nature considering the climate of the COVID- 19 pandemic and unauthorised disclosure could have caused the individuals to experience discrimination or social stigma; 5 Mitigating Factors 22 (b) The Organisation had to operationalise the Portal under urgent circumstances; (c) The Organisation took prompt remedial actions following the Incident; and (d) The Organisation was cooperative during the investigations. Having considered the above factors and circumstances, the Commissioner preliminarily determined that a financial penalty of $12,000 would be imposed in respect of the Organisation’s negligent contravention of the Protection Obligation. On 22 April 2021, the Organisation was notified of the Commissioner’s preliminary decision, including the full findings set out above, and given 14 days to make written representations. The Organisation’s representations 23 On 7 May 2021, the Organisation submitted written representations requesting that it be issued a warning in lieu of a financial penalty. While the Organisation did not dispute that it had breached the Protection Obligation, it claimed that the circumstances of its case were similar or less egregious to recent enforcement decisions of the Commission in which warnings had been given to organisations for breaches of the Protection Obligation2. 24 According to the Organisation, unlike in the precedent cases cited: (a) Only 4 individuals’ personal data was affected in the Incident (i.e. a very low number); (b) The personal data affected (i.e. the SHN Data) was not sensitive; (c) There was no exfiltration or public exposure of the SHN Data; (d) Prompt remedial measures were implemented within 48 hours with no loss of personal data; and 2 Chan Brothers Travel Pte Ltd (DP-1905-B3936, Summary of the Decision); Horizon Fast Ferry Pte Ltd (DP1912-B5464, Summary of the Decision); MRI Diagnostics Pte Ltd (DP-1811-B2975, Summary of the Decision); Water+Plants Lab Pte Ltd (DP-2004-B6182, Summary of the Decision); R.I.S.E Aerospace Pte Ltd (DP-2007-B6832, Summary of the Decision); Everlast Projects Pte Ltd [2020] SGPDPC 20; Chapel of Christ the Redeemer (DP-2010-B7132, Summary of the Decision); St Joseph’s Institution International Ltd (DP-2010B7196, Summary of the Decision); and ACCA Singapore Pte Ltd (DP-2011-B7385, Summary of the Decision). 6 (e) Reports were voluntarily made to the authorities (including ICA and the police) and the Organisation was not held to ransom or complained about by any members of the public. 25 The Organisation also claimed that unauthorised disclosure of the SHN Data would not have caused the affected individuals to experience discrimination or social stigma. The Organisation claimed that it was normal for anyone entering Singapore at the time to be subject to an SHN, and that many persons had even publicised this fact. With reference to the precedent cases cited, the Organisation claimed that the disclosure of (i) students’ grades, (ii) church members’ marital statuses, and (iii) employees’ salaries, carried a greater risk of the affected persons experiencing discrimination or social stigma in the relevant circumstances. 26 After careful consideration, the Organisation’s representations were rejected. 27 While there may have been facts in specific domains of the precedent cases which appeared either similar or more egregious than the Incident, this did not mean that the Organisation was deserving of a warning. Every case is decided based on an evaluation of all the relevant facts and circumstances, and in a manner that is fair and appropriate for the particular organisation investigated. 28 There are two main distinguishing factors which justifies the imposition of a financial penalty in the Organisation’s case compared to the precedent cases cited: (a) First, contrary to the Organisation’s representations, the SHN Data is considered to have been sensitive at the material time, during the early days of the COVID-19 pandemic when there was uncertainty about its virulence and high levels of public health concerns. The Organisation was engaged to help administer the SHN regime as part of a national effort to manage the pandemic. While the SHN Data did not include positive diagnoses for COVID-19, the fact of being subject to an SHN nevertheless denoted risk of exposure to the virus. The fact that the Incident occurred in July 2020 just after the end of “circuit breaker” measures and when public concern was high, was important context. (b) Second, within the same context of a national health emergency, the Organisation’s level of culpability was much higher than that of the organisations in 7 the cited precedents. The Organisation employed very poor access control measures which were easily circumvented by an unsophisticated actor. A common password was used by over 50 users and shared over an unsecure platform, with no audit trail. While the Organisation’s representations focused solely on the alleged harm caused by the Incident and the remedial steps taken afterwards, the extent of the Organisation’s negligence in the Incident was also an important factor which justified the imposition of a financial penalty in its case. 29 For completeness, the Organisation’s representations also failed to account that the personal data of 125 individuals was exposed to the risk of unauthorised access in the Incident, notwithstanding that only 4 records had been modified. In any event, the fact that the Incident only affected a limited number of persons has been taken into account in calibrating the quantum of the financial penalty imposed. Other factors raised by the Organisation such as the prompt implementation of remedial measures and voluntary reporting have similarly been accounted for. 30 Having considered all the relevant factors of this case, the Commissioner hereby requires the Organisation to pay a financial penalty of $12,000 within 30 days from the date of the relevant notice accompanying this decision, failing which interest at the rate specified in the Rules of Court in respect of judgment debts shall accrue and be payable on the outstanding amount of such financial penalty until the financial penalty is paid in full. 31 In view of the remedial actions that have already been taken by the Organisation, no other directions are necessary. YEONG ZEE KIN DEPUTY COMMISSIONER FOR COMMISSIONER FOR PERSONAL DATA PROTECTION 8 ",Financial Penalty,72732e0dda0822fd38160244a8fdf6eca77d9bca,"[""tags"",""decision"",""pdf-url"",""description"",""date"",""timestamp"",""url"",""title"",""nature"",""pdf-content""]" 2023-10-01T11:02:10+08:00,fbd32491db44d3d0c97aa12a99cefd61ec954264,26,26,1,1016,"A financial penalty of $67,000 was imposed on Quoine for failing to put in place reasonable security arrangements to protect the personal data in its possession.","[""Protection"", ""Financial Penalty"", ""Finance and Insurance""]",2022-07-14,https://www.pdpc.gov.sg/-/media/Files/PDPC/PDF-Files/Commissions-Decisions/Decision---Quoine-Pte-Ltd---08022022.pdf,Protection,Breach of the Protection Obligation by Quoine,https://www.pdpc.gov.sg/all-commissions-decisions/2022/07/breach-of-the-protection-obligation-by-quoine,2022-07-14,"PERSONAL DATA PROTECTION COMMISSION [2022] SGPDPC 2 Case No. DP-2011-B7409 / DP-2011-B7421 In the matter of an investigation under section 50(1) of the Personal Data Protection Act 2012 And Quoine Pte Ltd … Organisation DECISION Quoine Pte Ltd [2022] SGPDPC 2 Lew Chuen Hong, Commissioner — Case Nos. DP-2011-B7409 / DP-2011-B7421 8 February 2022 Introduction 1 On 17 November 2020, Quoine Pte Ltd (“the Organisation”) informed the Personal Data Protection Commission (“the Commission”) that its domain manager had transferred control of its domain hosting account to an external actor, who accessed and exfiltrated the personal data of 652,564 of its customers (“the Incident”). The Commission subsequently received a complaint from an individual believed to have been affected in the Incident. 2 The Organisation requested for the investigation to be handled under the Commission’s Expedited Breach Decision procedure. In this regard, the Organisation voluntarily provided and admitted to the facts set out below, and admitted that it had failed to implement reasonable security arrangements to protect the personal data accessed and exfiltrated in the Incident in breach of Section 24 of the Personal Data Protection Act 2012 (“PDPA”). Facts of the Case 3 The Organisation is a company incorporated and based in Singapore, and a subsidiary of Liquid Group Inc., which is incorporated in Japan. The Organisation operates a global cryptocurrency exchange under the “Liquid” brand, and has customers around the world. 4 At the time of the Incident, the Organisation’s back-end IT infrastructure included the following: (a) Its vendor-procured cloud computing platform (“Cloud Platform”) which it used to run its cryptocurrency exchange platform, and which hosted its cloud computing database; and (b) Its additional cloud computing storage procured from another vendor, which it used to store documents such as Know-Your-Client (“KYC”) documents. 5 The Organisation also engaged a third party domain name registrar (“the Domain Provider”) to register and host the Organisation’s domain (@quoine.com domain). A domain name registrar allows a party to purchase and register domain names, where the domain name translates to a public address of the party’s servers (e.g. webserver, email server) for routing purposes. 6 On 13 November 2020, a staff member of the Organisation received an email from the Domain Provider stating that changes had been made to the settings of the Organisation’s domain hosting account with the Domain Provider (@quoine.com domain) (“Domain Hosting Account”). Staff members also received password reset emails for accounts on the Organisation’s other file-sharing and office productivity services. As the Organisation had not requested for the changes, the Organisation followed up with the Domain Provider, who acknowledged that the Organisation’s email accounts on its domain with the Domain Provider were no longer routed to the Organisation. 7 Investigations revealed that: (a) As a result of social engineering attacks on employees of the Domain Provider, an employee of the Domain Provider incorrectly transferred control of the Organisation’s Domain Hosting Account to an external actor. This allowed the external actor to change the registered email address on the Organisation’s Domain Hosting Account and subsequently effect a password reset on the account to take control of the Domain Hosting Account. (b) Control of the Domain Hosting Account allowed the external actor to know the number of servers using the domain name, and the IP addresses of these servers. (c) With control of the Domain Hosting Account, the external actor changed the servers to which the Organisation’s email traffic was directed (i.e. via changes to the Organisation’s mail exchanger (MX) records), from the email servers used by the Organisation to the external actor’s email servers. This redirected all of the Organisation’s emails to the external actor’s email servers. According to the Organisation, this impacted the Organisation’s security monitoring capability as many alerts and notifications, which were distributed via email, were consequently redirected to the external actor’s email servers. The Organisation’s staff members continued to receive emails notifying of changes to the settings of the Domain Hosting Account (referred to at [6] above) on alternative recovery options that had been set up. (d) Having redirected the Organisation’s emails on the Organisation’s domain (@quoine.com domain) to itself, the external actor then initiated password resets for several of the services tied to the Domain Hosting Account. The external actor successfully carried out a password reset on an account (“DevOps Account”) used by the Organisation for automation tasks and to run codes throughout the day which was not used interactively by humans. (e) The external actor then used the DevOps Account’s newly reset credentials to access the Organisation’s Cloud Platform, which hosted API keys/token to the Organisation’s database hosted within the Cloud Platform as well as a separate cloud computing storage database (collectively, the “Databases”). The external actor thereby gained credentials to the Databases, and accessed and exfiltrated personal data stored in the Databases. 8 The personal data of 652,564 of the Organisation’s customers was accessed and exfiltrated in the Incident, comprising the following: (a) First name and surname; (b) Address; (c) Email address; (d) Telephone number (optional); (e) Photo-image of documents provided by 362,035 customers for KYC purposes before 13 October 2018, namely, NRIC number, passport number or other identification documents, proof of address document, and photograph; (f) Financial information of Japanese customers of Quoine Corporation, a Japanese company related to the Organisation; (g) Transaction information: fiat deposits and crypto withdrawals, and a 2018 record of balances prior to the launch of the current “Liquid Exchange”; and (h) For customers depositing and withdrawing fiat currencies: Bank account and other information, namely, name of the bank, account number and name of the account holder. (collectively, the “Customer Data”). Remedial actions 9 Following the Incident, as part of remedial actions, the Organisation: (a) Notified its customers to alert them of the Incident, advised them of actions to take to secure their accounts, and recommended precautionary measures to monitor any suspicious activities which may have suggested improper use of their personal information; (b) Moved its domains to a more robust service provider that offered Enterprise level support, strong access control (username, password and mandatory two-factor authentication (“2FA”)) and roles-based access controls; (c) Migrated the entire Liquid exchange to a different vendor-provided cloud computing platform, with additional improvements made in the interactions between the Organisation’s service accounts and the system; and (d) Strengthened the use of the DevOps Account, and imposed IP whitelist restrictions where appropriate. 10 The Organisation is also evaluating other services to further harden its infrastructure, including cloud security configuration tools. Findings and Basis for Determination Whether the Organisation had contravened the Protection Obligation 11 Section 24 of the Personal Data Protection Act 2012 (“PDPA”) requires an organisation to protect personal data in its possession or under its control by making reasonable security arrangements to prevent unauthorised access, collection, use, disclosure, copying, modification, disposal or similar risks (the “Protection Obligation”). 12 As a preliminary point, while the Organisation had engaged the Domain Provider to host the Organisation’s domain, the Domain Provider did not process any personal data on behalf of the Organisation and was not the Organisation’s data intermediary. Due consideration is given to the fact that the initial breach occurred with the Domain Provider. The basis of the Commission’s decision is that the Protection Obligation in respect of the Customer Data was borne solely by the Organisation and there were failures in respect of how it secured access to its Cloud Platform, leading to the unauthorised disclosure of Customer Data. 13 The Commission has repeatedly highlighted that an organisation should design and organise its security arrangements to fit the nature of the personal data held by the organisation and the possible harm that might result from a security breach, and implement robust policies and procedures for ensuring appropriate levels of security for personal data of varying levels of sensitivity (see the Commission’s Advisory Guidelines on Key Concepts in the Personal Data Protection Act (revised 1 October 2021) (“Advisory Guidelines”) at [17.3]; see also Credit Counselling Singapore [2017] SGPDPC 18 at [25] and PeopleSearch Pte. Ltd. [2019] SGPDPC 47 at [10]). As stated in the Commission’s Advisory Guidelines at [17.5], measures that an organisation can use to protect personal data include adopting appropriate access controls (e.g. considering stronger authentication measures where appropriate) and installing appropriate computer security software and using suitable computer security settings. 14 Considering the Organisation’s business as a global cryptocurrency exchange that regularly deals with a large volume of sensitive personal data of a financial nature, the Organisation’s overall data protection and cybersecurity posture should have been very much heightened. The Organisation was in possession of 822,096 individuals’ Customer Data, including photo-image of documents and other information provided by 362,035 customers for KYC purposes, cryptocurrency transactions and bank account information. Consequently, the Organisation is required under the Protection Obligation to have implemented strong security arrangements to protect the Customer Data held in its Databases. 15 In the present case, the Organisation has admitted that it failed to implement reasonable security arrangements to protect the Customer Data, and that it was in breach of the Protection Obligation. In particular, the Organisation (i) failed to review and assess the DevOps Account’s security implications and risks, and (ii) failed to implement reasonable ICT controls for the DevOps Account. Failure to review and assess the DevOps Account’s security implications and risks 16 The Commission has highlighted in previous decisions the importance of carrying out correctly-scoped periodic security reviews, so as to detect vulnerabilities and assess security implications and risks, and to ensure that reasonable security arrangements have been put in place to protect personal data in an organisation’s database. 17 In WTS Automotive Services Pte. Ltd. [2018] SGPDPC 26 (“WTS”), the Commission highlighted the importance of conducting regular reviews to ensure that websites collecting personal data and electronic databases storing personal data have “reasonable security arrangements to prevent unauthorised access, collection, use, disclosure, copying, modification, disposal or similar risks”, as personal data of individuals may be exposed if a website or database in which it is stored contains vulnerabilities (at [18] of WTS). 18 Likewise, in Commeasure Pte Ltd [2021] SGPDPC 11 (“Commeasure”), the organisation had neglected to include the affected application package and access key (which the threat actor had used to access and exfiltrate personal data in the organisation’s cloud database) in its inventory of IT assets in production, which had resulted in their omission from its periodic security reviews. The organisation was found in breach of the Protection Obligation on this basis, as the vulnerability could otherwise have been discovered and the incident could have been prevented (at [16][17] of Commeasure). While the organisation explained that its failure to implement sufficiently robust processes to manage its inventory of infrastructure access keys was attributable to the high turnover of its employees from the time of its inception to the discovery of the incident, this was unacceptable because the organisation’s responsibility to protect personal data in its control or possession ought not to have been subjected to staff movement or appointment (at [13] of Commeasure). 19 As held in Chan Brothers Travel Pte Ltd [2020] SGPDPCS 11 (“Chan Brothers”), organisations must be aware of security implications of software features of their IT systems, so as to configure the security settings to enable effective protection of personal data stored in the IT systems (at [5] of Chan Brothers). 20 During the investigations, the Organisation admitted that its periodic reviews of access “failed to acknowledge this weakness as they incorrectly focussed on accounts used interactively by humans only, and not the automation bot accounts”. According to the Organisation, until the Incident, it was not aware of the vulnerability and weakness in access control to the DevOps Account, which did not have 2FA enabled. Accordingly, similar to the facts of Commeasure as set out above, although the Organisation had conducted periodic security reviews, these security reviews were improperly scoped, and failed to identify this vulnerability present in the DevOps Account. 21 The Organisation also admitted that the DevOps Account “was created without sufficient due diligence being given to the entire security risk profile of this type of account”, and “[t]his is a vulnerability that had not been adequately assessed by implementing alternative security measures to address the lack of 2FA”. 22 The Organisation had therefore failed to review and assess the security implications and risks arising from the DevOps Account and its lack of 2FA. The Organisation’s failures in this regard were especially egregious, given that the DevOps Account had privileged access to the Organisation’s Cloud Platform containing API keys/tokens to the Databases, and consequently, the Customer Data stored in the Databases. If the Organisation had included the DevOps Account in its security review and detected the vulnerabilities in the lack of 2FA, and/or had assessed and appreciated the security implications and risks arising from the DevOps Account and its lack of 2FA, it could have taken reasonable security measures to mitigate these security risks and to configure the security settings to enable effective protection of the Customer Data in the Databases. 23 The Organisation informed the Commission during the investigations that its current staff were not aware of the reasons for the DevOps Account’s set-up and security arrangements, as the DevOps Account had been created “at some time in the past (so legacy)”. The Organisation explained that there had been internal personnel movement. For instance, its DevOps team had initially been based in and managed out of Tokyo, then Quoine Vietnam. However, by mid-2020, the DevOps Tokyo team was no longer with the Organisation, and the DevOps team that remained was in Quoine Vietnam. While we are sympathetic to the challenges presented as a result of any personnel movements, it was incumbent on the Organisation to implement the necessary systems and processes to ensure that critical information about its IT systems, including legacy systems, survived the turnover of its staff. As the Commission has also held in Commeasure and stated above, an organisation’s responsibility to protect personal data in its control or possession ought not to have been subjected to staff movement or appointment. 24 The Organisation suggested that the DevOps Account’s security risk profile had not been assessed, probably due to its intended use as an automation account. This was not accepted. The Organisation is not exempted from assessing the security implications and risks of the DevOps Account simply on the basis that it was an automation account, especially considering that the DevOps Account could be used to access the Customer Data stored in the Databases. 25 In view of the above, the Organisation was found to be in breach of the Protection Obligation for its failure to review and assess the DevOps Account’s security implications and risks. Failure to implement reasonable ICT controls for DevOps Account 26 As stated in the Commission’s Guide to Data Protection by Design for ICT Systems (2021), organisations should put in place ICT controls to manage data protection risks (at page 9). Examples of ICT controls include setting appropriate access control rules, access rights and restrictions for specific user roles, and strengthening database security (at pages 15 and 18). 27 The Organisation informed the Commission that 2FA had not been implemented for the DevOps Account, which had privileged access to the Cloud Platform containing API keys/tokens to the Databases, and consequently, the Customer Data stored in the Databases. This meant that the DevOps Account is an account with privileged access. Many of the Organisation’s other systems and services had implemented 2FA for accounts with privileged access, and these were not breached in the Incident as the external actor could not carry out a password reset on these systems and services. In the present case, the external actor had been able to access the Cloud Platform and the API keys/tokens to the Databases stored therein, after carrying out password reset on the DevOps Account. 28 The Organisation could have guarded against this risk by strengthening ICT controls for the DevOps Account. The Organisation could have limited access to the password change functions of its DevOps Account. The Organisation could have introduced an additional restriction on the password change function, by requiring 2FA whenever there is a request to change passwords for the DevOps Account. The Organisation had implemented this additional restriction for many of its systems and services, which were not breached in the Incident as the external actor could not carry out a password reset where 2FA was required. The Organisation could likewise have implemented a 2FA requirement for effecting password resets for the DevOps Account. This was an existing policy and practice that the Organisation had for other accounts with privileged access, and it ought to also have been extended to the DevOps Account which also had privileged access. 29 Accordingly, the Organisation was found to be in breach of the Protection Obligation for failing to implement reasonable ICT controls for the DevOps Account. The Commissioner’s Directions 30 In determining whether to impose a financial penalty on the Organisation pursuant to section 48J(1) of the PDPA, and the amount of any such financial penalty, the matters set out at section 48J(1) and the factors listed at section 48J(6) of the PDPA were taken into account, as well as the following mitigating factors: Mitigating Factors (a) The Organisation took prompt remedial actions, including notifying the affected individuals; and (b) 31 The Organisation was cooperative during investigations. The Commission also considered the Organisation’s voluntary acceptance of liability for the Incident. 32 Having considered all the relevant factors of this case, the Commissioner hereby requires the Organisation to pay a financial penalty of $67,000 within 30 days from the date of the relevant notice accompanying this decision, failing which interest at the rate specified in the Rules of Court in respect of judgment debts shall accrue and be payable on the outstanding amount of such financial penalty until the financial penalty is paid in full. 33 No further directions are necessary on account of the remedial measures already taken by the Organisation. YEONG ZEE KIN DEPUTY COMMISSIONER FOR COMMISSIONER FOR PERSONAL DATA PROTECTION ",Financial Penalty,050d292466354174c1fddecc90ae2ad45a68f635,"[""tags"",""decision"",""pdf-url"",""description"",""date"",""timestamp"",""url"",""title"",""nature"",""pdf-content""]" 2023-10-01T11:02:10+08:00,fbd32491db44d3d0c97aa12a99cefd61ec954264,27,27,1,1016,Both organisations were found not in breach of the PDPA in relation to complaints regarding alleged collection and disclosure of personal data without consent.,"[""Consent"", ""Not in Breach"", ""Real Estate"", ""No breach""]",2022-06-16,https://www.pdpc.gov.sg/-/media/Files/PDPC/PDF-Files/Commissions-Decisions/Decision---SLP-Scotia-Pte-Ltd-and-SLP-International-Property-Consultants-Pte-Ltd---09042022.pdf,Consent,No Breach of the Consent Obligation by SLP Scotia and SLP International Property Consultants,https://www.pdpc.gov.sg/all-commissions-decisions/2022/06/no-breach-of-the-consent-obligation-by-slp-scotia-and-slp-international-property-consultants,2022-06-16,"PERSONAL DATA PROTECTION COMMISSION Case No. DP-2007-B6585, DP-2007-B6591, DP-2007-B6594, DP-2007-B6598 In the matter of an investigation under section 50(1) of the Personal Data Protection Act 2012 And SLP Scotia Pte. Ltd. SLP International Property Consultants Pte. Ltd. SUMMARY OF THE DECISION 1. Between 10 to 14 July 2020, the Personal Data Protection Commission (the “Commission”) received four complaints against SLP International Property Consultants Pte Ltd (“SLPIPC”) and its subsidiary SLP Scotia Pte Ltd (“SLPS”) (collectively, the “Organisations”). The complainants were property agents registered through SLPS (the “Complainants”). 2. As a merger was due to take place between the Organisations, on 7 July 2020, SLPIPC initiated the registration of salespersons in SLPS as salespersons in SLPIPC with the Council of Estate Agencies (“CEA”). CEA thereafter emailed the Complainants asking them to either initiate a salesperson application to join SLPIPC or disregard the email if they were not interested in registering with SLPIPC (the “Incident”). 1 3. The Complainants alleged that: a. they had not consented to be contacted for such purposes; and b. SLPS had improperly disclosed their personal data (including NRIC number, date of birth, and home address) to SLPIPC, and SLPIPC had in turn improperly disclosed the data to CEA. 4. CEA is the entity which administers the registration of salespersons (such as the Complainants) under the Estate Agents Act 2010 (“EAA”). Pursuant to section 29(1) of the EAA, a person may not act as a salesperson for any estate agent unless he or she is registered; the said register is maintained by the CEA pursuant to section 36 of the EAA. Further, under section 40(1) of the EAA, a salesperson may not be registered to act as a salesperson for more than one estate agent at any one time. 5. SLPIPC disclosed the personal data of the Complainants to CEA for the purposes of the change in registration from SLPS to SLPIPC. In doing so, SLPIPC was complying with its obligations under the EAA. The disclosure by SLPIPC to CEA was therefore not in breach of any of the provisions of the Personal Data Protection Act 2012 (“PDPA”), as under section 4(6) of the PDPA, obligations of a party under other written law take precedence over obligations under the PDPA. 2 6. The Commission’s investigation focused on whether the Organisations had breached the Consent Obligation under section 13 of the PDPA in relation to: a. the disclosure of the Complainants’ personal data by SLPS to SLPIPC; and b. the collection of the said data by SLPIPC from SLPS. 7. Investigations revealed that the Complainants had each, individually and separately, signed an agreement with SLPS (“Associate’s Agreement”) in which they had provided their consent for disclosure of their personal data in specific circumstances. Notably: a. Clause 24 of the Associate’s Agreement provided that the Complainants consented to SLPS collecting, using and/or disclosing their personal data for one or more of the “Company Purposes”. b. “Company Purposes” as defined in the Associate’s Agreement included disclosure of the Complainants’ personal data to SLPS’ related corporations, to facilitate and administer the real estate brokerage services to be provided by the Complainants under the Associate’s Agreement. c. As SLPS was a subsidiary of SLPIPC, both Organisations were “related corporations” for the purposes of the Associate’s Agreement. 8. The disclosure and collection of the Complainants’ personal data had been carried out because of an upcoming merger between the Organisations, for business reasons. With the move towards merger at the material time, the Complainants had 3 the option of providing their services under SLPIPC after the merger. This was found to fall under the ambit of “Company Purposes” pursuant to Clause 24 of the Associate’s Agreement, because the merger would have affected the Complainants’ ability to “facilitate and administer” their real estate brokerage services. 9. Consequently, the disclosure of the Complainants’ personal data by SLPS and the collection and disclosure of the same by SLPIPC as a related corporation was found to be consistent with the purposes for which the Complainants had provided consent in the Associate’s Agreement. 10. In light of the above, the Deputy Commissioner for Personal Data Protection finds that the Organisations did not breach the Consent Obligation under section 13 of the PDPA. The following is the provision of the Personal Data Protection Act 2012 cited in the above summary: Consent required 13. An organisation must not, on or after 2 July 2014, collect, use or disclose personal data about an individual unless — (a) the individual gives, or is deemed to have given, his or her consent under this Act to the collection, use or disclosure, as the case may be; or (b) the collection, use or disclosure (as the case may be) without the individual’s consent is required or authorised under this Act or any other written law. 4 ",Not in Breach,81943b55f3e50d31e820edf46499ec3602f370c0,"[""tags"",""decision"",""pdf-url"",""description"",""date"",""timestamp"",""url"",""title"",""nature"",""pdf-content""]" 2023-10-01T11:02:10+08:00,fbd32491db44d3d0c97aa12a99cefd61ec954264,28,28,1,1016,Aman was found not in breach of the PDPA in relation to an incident involving unauthorised access to its servers and exfiltration of personal data. Aman had employed reasonable security arrangement and technical measures to protect its data.,"[""Protection"", ""Not in Breach"", ""Accommodation and F&B""]",2022-06-16,https://www.pdpc.gov.sg/-/media/Files/PDPC/PDF-Files/Commissions-Decisions/Decision--Aman-Group-Sarl-and-or-Amanresort-International-Pte-Ltd--28022022.pdf,Protection,No Breach of the Protection Obligation by Aman Group S.a.r.l and Amanresort International,https://www.pdpc.gov.sg/all-commissions-decisions/2022/06/no-breach-of-the-protection-obligation-by-aman-group,2022-06-16,"PERSONAL DATA PROTECTION COMMISSION Case No. DP-2012-B7506 In the matter of an investigation under section 50(1) of the Personal Data Protection Act 2012 And Aman Group S.a.r.l and/or Amanresort International Pte Ltd SUMMARY OF THE DECISION 1. On 5 December 2020, the Personal Data Protection Commission (the “Commission”) received a notification from SingCERT of a personal data breach involving Aman Group S.a.r.l (“Aman Group”) and/or Amanresort International Pte Ltd (“Aman SG”). 9 systems in London and 2 systems in Singapore were compromised and files containing personal data exfiltrated (the “Incident”). Page 1 of 4 2. As a result of the Incident, personal data of approximately 2,500 individuals which included their name, date of birth, address, email address, phone number and profession were affected. 3. The Aman Group engaged an external cybersecurity company, Ankura Consulting, to investigate the Incident. Its investigations found that the threat actor(s) had gained unauthorised access into 11 systems, which included 9 servers based in London and 2 servers based in Singapore. 4. While the investigations did not uncover any evidence of what the initial method and point of entry were, the most likely scenario is that the threat actor had initially entered via the London based systems. This is because the suspicious activities were first detected in the London systems. Thereafter, the threat actor subsequently gained access to the 2 Singapore based servers by creating administrator account credentials. There was no evidence that the firewalls in the Singapore based servers were breached. 5. Investigations could not conclusively exclude the possibility that data may have been exfiltrated from one of the Singapore based servers. However, analysis conducted by the Aman Group on four extracts obtained from the threat actor(s) failed to establish any conclusive links between the extracts and the current database in the affected Singapore based server. 6. Investigations further revealed that any exfiltrated data would have been encrypted and was in a proprietary format. Aman Group’s assessment was that Page 2 of 4 the encryption and the proprietary format made it unlikely that the threat actor(s) would be able access and recreate the data in plaintext. Their assessment is that even if there had been exfiltration, there was no evidence that the exfiltrated data was in fact compromised. This is because the extracts obtained from the threat actor(s) do not resemble the current database in the affected Singapore based server. 7. Following the Incident, the Aman Group took prompt and extensive remedial actions to mitigate the effects of the Incident and enhance the robustness of its security measures. 8. Further, based on the facts as disclosed, Aman SG is a regional office. It did not hold the data protection role and was not in possession or control of the personal data in the 2 Singapore based servers. As such, Aman SG could not be held accountable for the Incident and cannot be said to be in breach of the Protection obligation under section 24 of the PDPA. 9. In view of the above, the Deputy Commissioner for Personal Data Protection is satisfied of the view that the Aman Group had met its Protection obligation under section 24 of the Personal Data Protection Act (“PDPA”) and that no enforcement action needs to be taken in relation to the Incident. Page 3 of 4 The following provision(s) of the Personal Data Protection Act 2012 had been cited in the above summary: Protection of personal data 24. An organisation shall protect personal data in its possession or under its control by making reasonable security arrangements to prevent – (a) unauthorised access, collection, use, disclosure, copying, modification, disposal or similar risks; and (b) the loss of any storage medium or device on which personal data is stored. Page 4 of 4 ",Not in Breach,5e015c5637baabcfc9d1ffcaae0eb7490cbabe57,"[""tags"",""decision"",""pdf-url"",""description"",""date"",""timestamp"",""url"",""title"",""nature"",""pdf-content""]" 2023-10-01T11:02:10+08:00,fbd32491db44d3d0c97aa12a99cefd61ec954264,29,29,1,1016,"Ngian Wen Hao Dennis, Chua Puay Hwa Melissa and Winarto were found in breach of the PDPA and issued warnings in relation to two incidents involving the unauthorised collection and disclosure of individuals’ personal data in 2019 and 2020.","[""Consent"", ""Notification"", ""Warning"", ""Finance and Insurance""]",2022-06-16,https://www.pdpc.gov.sg/-/media/Files/PDPC/PDF-Files/Commissions-Decisions/Decision---Dennis-Ngian--Others---08032022.pdf,"Consent, Notification",Breach of the Consent and Notification Obligations by three insurance financial advisers,https://www.pdpc.gov.sg/all-commissions-decisions/2022/06/breach-of-the-consent-and-notification-obligations-by-three-insurance-financial-advisers,2022-06-16,"PERSONAL DATA PROTECTION COMMISSION Case No. DP-2109-B8857 In the matter of an investigation under section 50(1) of the Personal Data Protection Act 2012 And (1) Ngian Wen Hao Dennis (2) Chan Puay Hwa Melissa (3) Winarto (4) Aviva Financial Advisers Pte Ltd SUMMARY OF THE DECISION 1. On 7 September 2021, the Personal Data Protection Commission (the “Commission”) was notified of two incidents involving unauthorised disclosure and collection of personal data by three individuals. 2. Ngian Wen Hao Dennis (“Dennis”) was an Aviva Financial Advisers Pte Ltd (“AFA”) representative between December 2017 and February 2019. In March 2019 and August 2020, Dennis approached two insurance financial advisers, Chua Puay Hwa Melissa (“Melissa”) and Winarto, to offer them a list of client leads, stating that he was leaving the insurance industry and looking for a reliable agent 1 to take over his clientele. Melissa and Winarto each said they paid $1,000 to Dennis for the list (the “Incidents”). 3. The list contained approximately 1,000 clients’ names, mailing addresses, contact numbers and the names of organisations underwriting the hospitalisation plans bought by the clients (“Personal Data Sets”). 4. The PDPA defines “organisations” to include individuals. As held in Re Sharon Assya Qadriyah Tang1, individuals who collect, use or disclose personal data otherwise than in a personal or domestic capacity will be treated as organisations within the meaning of the Act, and are obliged to comply with the Data Protection Provisions. In this case, we are of the view that it is clear that Dennis, Melissa and Winarto can be regarded as an “organisation” as defined under the PDPA for a number of reasons. First, the trio had bought and sold the client leads for work and business purposes, with the aim of generating an income or profit, and cannot be said to have been acting in a personal or domestic capacity. 5. Second, Dennis, Melissa and Winarto were not employees. In Re Ang Rui Song2, the Commission found that the respondent, a financial consultant with Prudential Assurance Company (Pte) Ltd, had been engaged on such terms that he was in effect an independent contractor rather than an employee of Prudential. The same applies to the trio. The Representative Agreement between AFA and Dennis 1 2 [2018]SGPDPC 1. [2017] SGPDPC 13. 2 expressly provides that “nothing in [the] Agreement shall constitute, or be construed, or deemed to constitute, any employment…between [Dennis] and [AFA]”. Dennis 6. Having found that the PDPA applies, we now turn to consider the data protection obligations applicable to the different parties concerned. Dennis conceded that he approached Melissa and Winarto to transfer his list of client leads to them. Our investigations revealed that Dennis’ claim that he had obtained the necessary consent and duly notified the clients on the list regarding the disclosure of their personal data to other insurance financial advisers could not be corroborated. None of the clients verified Dennis’ claim that he had contacted them to seek their consent or notified them of the disclosure of their personal data to other insurance financial advisers. We are therefore of the view that Dennis has breached the Consent and Notification Obligation under the PDPA in that he did not obtain his clients’ consent before disclosure of their personal data. Melissa and Winarto 7. Both Melissa and Winarto admitted to the collection (purchase) of the client list from Dennis. They claimed to have relied on the verbal assurances provided by Dennis that he had informed the clients about the change in their insurance financial adviser. In Re Amicus Solutions Pte Ltd and Ivan Chua Lye Kiat [2019] 3 SGPDPC 33 (at [49]), we stated that a reasonable person should undertake proper due diligence, such as obtaining from the seller a sample of the written notifications and consent. In our view, Melissa and Winarto have failed to take reasonable steps to verify from Dennis that there had been proper notification to and consent obtained from the clients for the disclosure of their personal data. In collecting (i.e. buying) the client list, we find that Melissa and Winarto are in breach of the Notification and Consent Obligations under the PDPA. AFA 8. The Commission found no evidence of breach of the PDPA by AFA in the Incidents. As stated in [5], Dennis was not an employee of AFA for whose acts AFA may be liable through section 53(1) of the PDPA. Dennis claimed that the Personal Data Sets were not retrieved from AFA’s systems and that he had compiled the list on his own accord to keep track of his clientele during his time as an independent financial adviser with AFA. This was consistent with AFA’s own investigations. Our investigations also revealed that AFA had reasonable policies and security measures in place for personal data protection. These included data leak prevention controls and monitoring of AFA corporate network to prevent representatives from exporting clients’ data from its systems. Contractual terms were also in place to require representatives to comply with the PDPA. AFA issued a letter to Dennis, upon the termination of the relationship between them, referring to the need to return “all policies, rate books, receipts, manuals, literature, lists and personal information of Customers”. 4 The Commission’s Decision 9. The sale of personal data by organisations without obtaining the consent of the individuals involved is a serious breach of the PDPA. In Re Sharon Assya Qadriyah Tang at [30], we had stated as follows: There are strong policy reasons for taking a hard stance against the unauthorised sale of personal data. Amongst these policy reasons are the need to protect the interests of the individual and safeguard against any harm to the individual, such as identity theft or nuisance calls. Additionally, there is a need to prevent abuse by organisations in profiting from the sale of the individual’s personal data at the individual’s expense. It is indeed such cases of potential misuse or abuse by organisations of the individual’s personal data which the PDPA seeks to safeguard against. In this regard, the Commissioner is prepared to take such stern action against organisations for the unauthorised sale of personal data. [Emphasis added.] 10. To curb this form of abuse of personal data, the amount of profit made by the organisation from the sale may be factored in determining the financial penalty that the organisation may be required to pay. Indeed, had the sale taken place after the 2020 amendments to the PDPA, this would have been a specific consideration under section 48J(6)(c): “whether the organisation or person (as the case may be), as a result of the non‑compliance, gained any financial benefit”. 11. In determining the enforcement action in response to the breach by Dennis, the Commission took into account the cooperation extended to the investigation, and 5 the full refund made by Dennis of the proceeds he made from the sale. The Commission also considered that Dennis is in poor health, has been unemployed since 2018, has little savings in his bank account, and is dependent on his aged father for financial support. Having considered the state of Dennis’ health and financial status, the Commission is of the view that a financial penalty would impose a crushing burden on him and his family, resulting in undue hardship. Accordingly, taking into account all relevant factors, the Commission has decided to administer a warning in respect of the breach by Dennis of the Consent and Notification Obligations. The Commission wishes to emphasize that this assessment that undue hardship may occur following the imposition of a financial penalty is not a finding that the Commission will make easily and will be reserved only for the most deserving and exceptional cases. Individuals who seek to misuse personal data for profit and are found to be in breach of the PDPA must expect to pay a heavy financial penalty. 12. Turning to Melissa and Winarto, the Commission has decided to administer warnings to Melissa and Winarto in respect of their breaches of the Consent and Notification Obligations. In so deciding, the Commission considered that both of them did not sell the personal data for profit and had been cooperative throughout the investigations. More importantly, neither of them used the personal data they obtained without consent from the individuals involved. 6 The following provisions of the Personal Data Protection Act 2012 (pre-amendment in 2020) had been cited in the above summary: Consent and Notification Obligations (Section 13 read with 20 of the PDPA) Pursuant to section 13 of the PDPA, unless an exception to consent is applicable, organisations are generally required to obtain the consent of an individual before collecting, using and/or disclosing the individual’s personal data (“Consent Obligation”). Consent must be obtained from the individual with reference to the intended purpose of the collection, use or disclosure of the personal data. The organisation’s collection, use and disclosure of personal data are limited to the purposes for which notification has been made to the individuals concerned. In this regard, organisations have an obligation under section 20 of the PDPA to inform individuals of the purposes for which their personal data will be collected, used and/or disclosed, on or before collecting the personal data in order to obtain consent (“Notification Obligation”). Protection Obligation (Section 24 of the PDPA) An organisation shall protect personal data in its possession or under its control by making reasonable security arrangements to prevent unauthorised access, collection, use, disclosure, copying, modification, disposal or similar risks. 7 ",Warning,11afc51e552a655c8c243aa724648b2011a2eb25,"[""tags"",""decision"",""pdf-url"",""description"",""date"",""timestamp"",""url"",""title"",""nature"",""pdf-content""]" 2023-10-01T11:02:10+08:00,fbd32491db44d3d0c97aa12a99cefd61ec954264,30,30,1,1016,"A financial penalty of $22,000 was imposed on Vhive for failing to put in place reasonable security arrangements to protect the personal data in its possession from a ransomware attack.","[""Protection"", ""Financial Penalty"", ""Wholesale and Retail Trade"", ""Ransomware""]",2022-06-16,https://www.pdpc.gov.sg/-/media/Files/PDPC/PDF-Files/Commissions-Decisions/Decision---Vhive-Pte-Ltd---08032022.pdf,Protection,Breach of the Protection Obligation by Vhive,https://www.pdpc.gov.sg/all-commissions-decisions/2022/06/breach-of-the-protection-obligation-by-vhive,2022-06-16,"PERSONAL DATA PROTECTION COMMISSION Case No. DP-2013-B8138 In the matter of an investigation under section 50(1) of the Personal Data Protection Act 2012 And Vhive Pte Ltd SUMMARY OF THE DECISION 1. On 26 March 2021, Vhive Pte Ltd (the “Organisation”) notified the Personal Data Protection Commission (the “Commission”) of a ransomware attack that affected its customer database (the “Incident”). Approximately 186,281 individuals’ names, addresses, email addresses, telephone numbers, hashed passwords and customer IDs were affected. 2. The Organisation subsequently requested for this matter to be handled under the Commission’s expedited breach decision procedure. This means that the Organisation voluntarily provided and unequivocally admitted to the facts set out in this decision, and admitted that it was in breach of section 24(a) of the Personal Data Protection Act (the “PDPA”). 3. The Organisation’s forensic investigation results revealed that the Organisation’s IT infrastructure had been outdated, with multiple vulnerabilities at the time of the Incident. The Organisation’s e-commerce server ran on an outdated webserver service. This, together with an unpatched firewall, allowed the threat actor to 1 remotely execute unauthorised code on the e-commerce server, and gained backdoor access to the e-commerce server to carry out the ransomware attack. 4. The Organisation had engaged an IT vendor to host, manage and maintain the e-commerce server and all its other IT systems. However, our investigations revealed that despite the purported “engagement”, there was in fact no written contract between the Organisation and its IT vendor at the time of the Incident. 5. In Re Spize Concepts Pte Ltd [2019] SGPDPC 22 at [22], we had stated that section 4(2) of the PDPA imposes on organisations that engage data intermediaries to do so “pursuant to a contract which is evidenced or made in writing”. In that case, we also highlighted that one specific category of policies and practices under section 12(a) of the PDPA that an organisation should develop and implement is the contractual documentation relating to the scope of the data intermediary relationship, and failure to do so would amount to a breach. The raison d’etre is that the outsourcing of data processing activities must be clearly scoped, and the respective roles and responsibilities between the organization and the data intermediary clearly identified from the outset. In the absence of any written contract and the lack of evidence to show the scope, roles and responsibilities of the data processing outsourcing, the Organisation remained solely responsible for complying with the obligations under the PDPA, including the obligation to make reasonable security arrangements to protect the personal data in its possession or under its control under section 24 of the PDPA. 6. The Organisation’s outdated webserver was used to host the Organisation’s website and its online storefront. In this regard, the Commission had previously 2 issued a Guide on Building Websites for SMEs in 2016, which was subsequently updated and revised in July 2018. In this Guide, the Commission emphasized the importance of ensuring the protection of personal data and the security of the website throughout the life cycle, including ensuring the clear delineation of responsibilities when an organization engages an IT vendor. 7. We wish to reiterate our observations in [4.2.1] of the Guide, where we highlighted the need to consider and properly document an IT vendor’s scope of work, and stated as follows: Organisations should emphasise the need for personal data protection to their IT vendors, by making it part of their contractual terms. The contract should also state clearly the responsibilities of the IT vendor with respect to the PDPA. When discussing the scope of outsourced work, organisations should consider whether the IT vendor’s scope of work will include any of the following: • Requiring that IT vendors consider how the personal data should be handled as part of the design and layout of the website. • Planning and developing the website in a way that ensures that it does not contain any web application vulnerabilities that could expose the personal data of individuals collected, stored or accessed via the website through the Internet. • Requiring that IT vendors who provide hosting for the website should ensure that the servers and networks are securely configured and adequately protected against unauthorised access. • Requiring IT vendors to ensure that all work done is fully documented and that all documentation is handed over to the organisation at the completion of the project. Documents should capture the website’s requirements, design specifications, user test scripts, user test results, as well as server and network configurations. • When engaging IT vendors to provide maintenance and/or administrative support for the website, requiring that any changes they make to the website do not contain vulnerabilities that could expose the personal data. Additionally, discussing whether they have technical and/or non-technical processes in place to prevent the personal data from being exposed accidentally or otherwise. 3 • 8. Requiring that IT vendors providing maintenance and/or administrative support to ensure that all changes to the website are secure and documented, and that the document is kept up to date. The Organisation admitted the weakness in its IT infrastructure and its failure to give due attention to the protection of the personal data of its customers had contributed to the Incident. 9. On the facts, the Organisation’s failure to ensure that there was a written contract with its IT vendor not only meant that there was a lack of clarity on the scope of work expected from the IT vendor, but also that the Organisation had failed to stipulate clear written security maintenance requirements and data protection requirements to its IT vendor to ensure the protection of personal data it was in control or in possession of. This ultimately resulted in a lack of system maintenance, including security maintenance by the Organisation. 10. Investigations further revealed that the Organisation did not have a security maintenance policy, which would have made up for the lack of specification of these requirements to its IT vendor, nor did the Organisation conduct any of its own scheduled security reviews, through which it could have detected any security inadequacy or vulnerabilities within its IT infrastructure. 11. In the above circumstances, the Organisation is found to have breached the Protection Obligation under section 24(a) of the PDPA. 12. Following the Incident, the Organisation decommissioned its e-commerce webserver and overhauled its IT infrastructure. Apart from deciding to conduct online sales solely through third party websites, the Organisation also rebuilt its ERP server in a secure environment with new set of firewalls, updated its 4 operating systems and software, implemented the use of SSL-VPN for remote access, and engaged a new IT vendor with the data security and data protection provisions properly specified in a written contract. The Organisation also reviewed and updated all its internal policies relevant to the protection of personal data. 13. In deciding the appropriate outcome in this case, the Commission acknowledges the cooperation extended by the Organisation to the Commission throughout the course of our investigations. The Organisation had also voluntarily admitted to its breach of the Protection Obligation, and took prompt remediation actions to address its security gaps. The Organisation was able to restore fully the personal data affected without loss, thereby minimizing any disruptions to its operations. 14. Having considered the circumstances set out above and the factors listed at section 48J(6) of the PDPA, the Commissioner for Personal Data Protection hereby finds the Organisation in breach and requires the Organisation to pay a financial penalty of $22,000 within 30 days from the notice accompanying date this decision, failing which interest at the rate specified in the Rules of Court in respect of judgment debts shall accrue and be payable on the outstanding amount of such financial penalty until the financial penalty is paid in full. 15. In view of the remedial action by the Organisation, no directions under section 48I are necessary. The following is the provision of the Personal Data Protection Act 2012 cited in the above summary: Protection of personal data 24. An organisation shall protect personal data in its possession or under its control by making reasonable security arrangements to prevent – 5 (a) unauthorised access, collection, use, disclosure, copying, modification, disposal or similar risks; and (b) the loss of any storage medium or device on which personal data is stored. 6 ",Financial Penalty,5c70e87aac9ad5ab303f0f8cb9f8f4094c224e02,"[""tags"",""decision"",""pdf-url"",""description"",""date"",""timestamp"",""url"",""title"",""nature"",""pdf-content""]" 2023-10-01T11:02:10+08:00,fbd32491db44d3d0c97aa12a99cefd61ec954264,31,31,1,1016,"Warnings were issued to Toll Logistics (Asia), Toll Global Forwarding, Toll Offshore Petroleum Services, and Toll (TZ) for breaches of the PDPA in relation to the transfer of employees’ personal data to a human resources software vendor in Ireland.","[""Transfer Limitation"", ""Warning"", ""Transport and Storage""]",2022-05-19,https://www.pdpc.gov.sg/-/media/Files/PDPC/PDF-Files/Commissions-Decisions/Decision--Toll-Logistics-Asia-Limited-and-others--180322.pdf,Transfer Limitation,Breach of the Transfer Limitation Obligation by Toll Logistics (Asia) and others,https://www.pdpc.gov.sg/all-commissions-decisions/2022/05/breach-of-the-transfer-limitation-obligation-by-toll-logistics-and-others,2022-05-19,"PERSONAL DATA PROTECTION COMMISSION [2022] SGPDPC 4 Case No. DP-2008-B6707 In the matter of an investigation under section 50(1) of the Personal Data Protection Act 2012 And (1) Toll Logistics (Asia) Limited (2) Toll Global Forwarding (Singapore) Pte. Limited (3) Toll Offshore Petroleum Services Pte. Ltd. (4) Toll (TZ) Pte. Ltd. … Organisations DECISION Toll Logistics (Asia) Limited and others [2022] SGPDPC 4 Yeong Zee Kin, Deputy Commissioner — Case No. DP-2008-B6707 14 March 2022 Introduction 1 Toll Holdings Limited (“Toll Holdings”) is an integrated logistics services provider headquartered in Australia. Toll Logistics (Asia) Limited (“Toll Logistics”), Toll Global Forwarding Singapore Pte. Ltd. (“Toll Forwarding”), Toll Offshore Petroleum Services Pte. Ltd. (“Toll Offshore""), and Toll (TZ) Pte. Ltd. (“Toll TZ”) are Singapore-registered entities (collectively, “the Organisations”) that are part of a multinational group of companies headed by Toll Holdings (“the Group”). 2 On 11 June 2020, Toll Holdings notified the Personal Data Protection Commission (“the Commission”) of a ransomware attack which had affected the Group’s IT systems, including servers in Australia and Singapore containing the personal data of current and former employees of the Organisations (“the Incident”). The Commission subsequently received complaints from 3 former employees of Toll Logistics in relation to the Incident. Investigations were commenced to determine whether the circumstances relating to the Incident disclosed any breaches by the Organisations of the Personal Data Protection Act 2012 (“PDPA”). Facts of the Case 3 In July 2013, Toll Holdings contracted with a vendor in Ireland (“the HR Vendor”) for the Group’s use of the HR Vendor’s human resources software platform (“the HR Platform”). To facilitate use of the common HR Platform, the respective Group entities (including the Organisations) uploaded the personal data of their employees to the HR Platform. The data uploaded to the HR Platform was hosted by the HR Vendor in data centres in the European Economic Area. 2 4 Subsequently in 2019, a series of Corporate Services Agreements (“CSAs”) and accession agreements were executed with the net effect that Toll Holdings undertook to provide finance, human resources (“HR”), information technology (“IT”), legal, and other corporate services to all the Organisations. Although the CSAs were inked in 2019, they took retrospective effect from 1 April 2018. 5 The services provided by Toll Holdings to the Organisations under the CSAs included: 6 (a) Development and maintenance of HR policies and procedures; (b) Development and maintenance of IT strategy; (c) Development and maintenance of IT policies and procedures; and (d) Provision of IT support services. Under the terms of the CSAs, Toll Holdings was permitted to appoint subcontractors to perform part or all of the services subject of the CSAs but was responsible to the same extent as if it had performed the services itself. 7 The scope of IT services to be provided by Toll Holdings under the CSAs specifically excluded the “development or implementation of IT systems”, which responsibility presumably remained with the Organisations. To this end, the Organisations maintained ten servers in Singapore to support their operations. Three of these servers (“the Singapore Servers”) were used by the Organisations’ corporate teams (i.e. finance, legal, HR) in the ordinary course of their work and contained personal data within the email archives and other working documents. 8 The Group (including the Organisations) had implemented various industry- standard security solutions for its IT systems such as end-point protection software, logging and monitoring software and/ services, firewall and intrusion prevention software, security detection and response software, identity access management and control software and services, vulnerability scanning software and services, and patching software. A Managed Security Service Provider (“MSSP”) was also engaged to provide cyber security detection and incident response services for the Group. With 3 the assistance of the MSSP and other external vendors, the Group carried out regular vulnerability scanning and penetration testing of its IT systems. Transfer of personal data to Australia 9 Sometime prior to the Incident, Toll Holdings’ Chief Human Resources Officer extracted personal data relating to 1,748 of the Organisations’ current and former employees from the HR Platform and transmitted them to a server in Australia (“the Australia Server”). Toll Holdings represented that this personal data was transferred for the purposes of performing services for the Organisations pursuant to the CSAs. 10 11 The personal data downloaded by Toll Holdings comprised each employee’s: (a) Name; (b) Address (c) Age; and (d) Salary. 5 employees of Toll Logistics and 2 employees of Toll Forwarding also had other datasets disclosed including: (a) Driver’s licence number; (b) Emergency contact details; (c) National ID; (d) Fingerprint; (e) Medical details; and (f) Passport details. 4 The Incident 12 On 26 April 2020, a malicious actor gained access to Toll Holdings’ IT environment in Australia using credentials stolen from a third-party vendor. The thirdparty vendor had been granted administrative access to two servers in Toll Holding’s IT environment in order to provide support services for a software solution. 13 Having gained access to the Group’s IT environment, the malicious actor used advanced malware and a range of hacking tools to move through the Group’s network, conduct reconnaissance, and escalate account privileges. The malicious actor also made various efforts to bundle and compress data from the Australia Server and stage it for exfiltration. 14 Threat monitoring software deployed by the Group detected events related to the malicious actor’s account takeover and privilege escalation during the Incident and raised alerts to the MSSP. However, according to Toll Holdings, no alerts were brought to its attention. On 3 May 2020, the malicious actor exfiltrated less than 2% (two percent) of the data stored on the Australia Server using a web-based file sharing service. The malicious actor then ran scripts to disable various endpoint protections across the Group and executed a ransomware attack. The ransomware attack encrypted files on a number of the Group’s servers, including the Australia Server and the Singapore Servers. 15 When subsequently making ransom demands, the malicious actor provided Toll Holdings a summary of the files exfiltrated from the Australia Server and eventually uploaded portions of the exfiltrated files onto the dark web. Based on (i) the summary provided by the malicious actor, (ii) the Group’s review of the available logs and records on the Australia Server, and (iii) a review of the files eventually published by the malicious actor on the dark web, the Organisations concluded that there was no evidence of exfiltration of the personal data of its current or former employees from the Australia Server. 16 The Organisations also concluded that there was no evidence of data exfiltration from the Singapore Servers, or any other servers in the Group’s IT environment in the Incident, other than the Australia Server. The Organisations were 5 able to restore the encrypted data in the Singapore Servers from securely stored backups. Remedial actions 17 Following the Incident, Toll Holdings implemented the following remedial measures on a Group-wide basis: (a) Temporarily disconnected from the Internet, and undertook a rolling shutdown of IT systems in order to mitigate spread of any infection; (b) Isolated all impacted servers and implemented network restrictions to prevent spread of the ransomware within the Group’s network; (c) Engaged third-party experts to assist with incident response, including investigation and remediation; (d) Upgraded its user access system and reset all administrator passwords; (e) Blocked the malware used in the Incident; (f) Removed access privileges obtained by the malicious actor; (g) Implemented additional vulnerability scanning across the Group’s IT systems to harden the Group’s network perimeter; (h) Strengthened the Group’s Active Directory infrastructure; (i) Implemented additional end point protection, forensic tools, and monitoring tools; (j) Introduced a shadow security operations centre and initiated transition to a new MSSP; (k) Initiated plans for an asset lifecycle review to identify legacy critical business applications and treatment required to address cyber risks; (l) Commenced a logging, monitoring and alerting uplift to review existing policies and standards; 6 (m) Completed the rollout of multi-factor authentication for all remote access; (n) Updated organisational measures such as incident response plans, policies, and playbooks; and (o) Rolled out a cyber awareness programme containing training and assignments for its employees Findings and Basis for Determination 18 Based on the circumstances of the Incident, the Commission’s investigation centred on: (a) Whether the Organisations had breached their respective obligations under section 26 of the PDPA to not transfer any personal data to a country or territory outside Singapore except in accordance with requirements prescribed under the PDPA (the “Transfer Limitation Obligation”); and (b) Whether the Organisations had breached their respective obligations under section 24 of the PDPA to protect personal data in their possession or under their control by making reasonable security arrangements to prevent unauthorised access, collection, use, disclosure, copying, modification, disposal or similar risks (the “Protection Obligation”). Whether the Organisations had contravened the Transfer Limitation Obligation 19 The HR Platform was implemented on a Group-wide basis on or around July 2013. The Organisations began uploading the personal data of their employees to the HR Platform for storage in the HR Vendor’s servers in the European Economic Area around this time, and would have continued to do so as part of the normal course of HR functions (for example, when new employees joined). Any transfers of personal data by the Organisations out of Singapore after 2 July 2014 would have been subject to the Transfer Limitation Obligation and the requirements prescribed in Part III of the Personal Data Protection Regulations 2014 (“PDPR 2014”). For transfers of personal data outside of Singapore which occurred after 1 February 2021, such transfers would 7 have been subject to the requirements in Part 3 of the Personal Data Protection Regulations 2021 (“PDPR 2021”). 20 Regulation 9(1)(b) of the PDPR 2014 and regulation 10(1) of the PDPR 2021 require an organisation that transfers personal data outside of Singapore to take appropriate steps to ensure that the recipient of the personal data is bound by legally enforceable obligations to provide the transferred personal data a standard of protection that is at least comparable to that under the PDPA. Under regulation 10 of the PDPR 2014 and regulation 11(1) of the PDPR 2021, such legally enforceable obligations can be imposed on the recipient organisation under (a) any law; (b) any contract between the parties; (c) binding corporate rules; or (d) any other legally binding instrument. 21 In gist, the Organisations were required to take appropriate steps to ensure that the personal data transferred out of Singapore via the HR Platform for storage in the European Economic Area would be protected to a standard comparable to under the PDPA, before any such transfers were made. 22 There was no evidence of any such steps taken by the Organisations. While the contract between Toll Holdings and the HR Vendor included data protection obligations imposed on the HR Vendor, the Organisations were not party to this agreement. The CSAs also did not contain any provisions relating to the protection of personal data or impose obligations on Toll Holdings to protect the personal data of the other Organisations for the purposes of the centralised corporate functions to be undertaken pursuant to the CSAs. Accordingly, the Organisations were determined to have contravened the Transfer Limitation Obligation in relation to the personal data uploaded on to the HR Platform. 23 In the course of investigations, Toll Holdings represented that it had since reviewed the data transfer arrangements under the CSAs and that the Organisations and Toll Holdings have now executed a “Singapore Data Export Agreement” to govern intra-group transfers of personal data from the Organisations to Toll Holdings (and other members of the Group who may subsequently become party to the agreement) 8 to ensure that a standard of protection comparable to the PDPA is provided to any transferred personal data. Whether the Organisations had contravened the Protection Obligation 24 As held in Everlast Projects Pte Ltd and others [2020] SGPDPC 20, members of a corporate group may satisfy the Protection Obligation by relying on binding grouplevel written policies or intra-group contracts which specify the respective data protection obligations of the members of the group. In the present case, while the Organisations had entered into the CSAs to centralise various corporate functions with Toll Holdings, the CSAs did not deal with data protection obligations. In the circumstances, the Protection Obligation remained with the Organisations, and the Organisations cannot rely on the CSAs to say that certain of its data protection operations had been centralised with Toll Holdings at the Group-level. 25 That being said, under the CSAs, Toll Holdings had undertaken to provide the Organisations with IT support services. It has been held in WTS Automotive Services Pte Ltd [2018] SGPDPC 26 that organisations can rely on the technical expertise of their service providers to satisfy the Protection Obligation (subject to clear instructions or business requirements being specified). In the case where a member of a group of companies provides technical support services to others in the group, it is advisable that their respective roles and responsibilities be clearly spelt out. 26 In the present case, the CSAs were intended to perform this role: Toll Holdings was responsible for IT support services while the Organisations remained responsible for development and implementation of IT systems: see [7] above. As part of the IT support services provided, Toll Holdings introduced and implemented Group-level IT security standards. These were communicated through the Group’s intranet and implemented by Toll Holdings on a Group-wide basis, as part of the IT support services they provided. In accordance with these standards, a number of industry-standard technical solutions and tools were implemented prior to the Incident to protect the personal data in the Singapore Servers: see [8] above. 27 Having considered these security arrangements, we are satisfied that the Organisations had not breached their Protection Obligation as the security 9 arrangements in place prior to and at the time of the Incident to protect the personal data in the Singapore Servers were reasonable and consistent with existing industry standards. In coming to this decision, we are also of the view that the security lapse and privilege escalation that enabled the malicious actor to overcome the Organisations’ endpoint protections in the Incident occurred abroad arising from theft of credentials from Toll Holdings’ vendor and was beyond the control of the Organisations. The Deputy Commissioner’s Decision 28 In determining what directions (if any) should be given to the Organisations pursuant to section 48I of the PDPA, the Deputy Commissioner took into consideration: (a) the Organisations’ cooperation with the Commission’s investigations; (b) that access to the transferred personal data was limited to entities within the same corporate group; (c) that there was no evidence of any loss or damage resulting from the Organisations’ contravention of the Transfer Limitation Obligation; and (d) that the Group had already implemented intra-group contractual arrangements to govern future transfers of personal data by the Organisations to Toll Holdings. 29 Having considered all the mitigating factors listed above, the Organisations are administered a warning in respect of their breach of the Transfer Limitation Obligation. No other directions are necessary in view of the remedial actions already taken by the Organisations. YEONG ZEE KIN DEPUTY COMMISSIONER FOR PERSONAL DATA PROTECTION 10 ",Warning,3366d27f6930503cebbbff6dd8de747f0da55d18,"[""tags"",""decision"",""pdf-url"",""description"",""date"",""timestamp"",""url"",""title"",""nature"",""pdf-content""]" 2023-10-01T11:02:10+08:00,fbd32491db44d3d0c97aa12a99cefd61ec954264,32,32,1,1016,"A financial penalty of $2,000 was imposed on Southaven Boutique for failing to put in place reasonable security arrangement to prevent the unauthorised access of its customers' personal data in its Point-Of-Sale system server. An application for reconsideration was filed against the Decision Re Southaven Boutique Pte Ltd. Upon review and careful consideration of the application, direction in the Decision was varied and the financial penalty imposed was reduced.","[""Protection"", ""Financial Penalty"", ""Wholesale and Retail Trade"", ""Ransomware""]",2022-05-19,https://www.pdpc.gov.sg/-/media/Files/PDPC/PDF-Files/Commissions-Decisions/Decision---Southaven-Boutique-Pte-Ltd---280222.pdf,Protection,Breach of Protection Obligation by Southaven Boutique,https://www.pdpc.gov.sg/all-commissions-decisions/2022/05/breach-of-protection-obligation-by-southaven-boutique,2022-05-19,"PERSONAL DATA PROTECTION COMMISSION Case No. DP-2102-B7854 In the matter of an investigation under section 50(1) of the Personal Data Protection Act 2012 And Southaven Boutique Pte Ltd 1 Editorial note: An application for reconsideration was filed against the decision in Re Southaven Boutique Ptd Ltd. Pursuant to this application, the Deputy Commissioner has decided to reduce the financial penalty imposed on the Organisation from $5,000 to $2,000. As the application did not give rise to significant legal or factual issues, a separate decision on the application will not be published. SUMMARY OF THE DECISION 1. On 5 February 2021, Southaven Boutique Pte Ltd (the “Organisation”), a brickand-mortar retailer of clothes and accessories, informed the Personal Data Protection Commission (the “Commission”) of a ransomware attack that occurred on or about 4 February 2021 (the “Incident”). A threat actor had gained access to the Organisation’s Point-Of-Sale (the “POS”) system server and encrypted the personal data of 4,709 customers. The personal data affected include names, addresses, email addresses, contact numbers and date of birth. 2. Investigations revealed that the Organisation did not implement adequate administrative and technical security arrangements. First, the Organisation failed to conduct or schedule any software updates, maintenance and/or security review before the Incident. Past decisions by the Commission had stressed the need for such security arrangements. The Organisation’s operating system and anti-virus software, for example, were outdated and updated only after the Incident. 3. Second, the Organisation had failed to set out any data protection requirements or responsibilities with the POS vendor whom the Organisation had engaged to supply and install the POS, and relied on for system service issue. This meant that the Organisation did not in fact engage the POS vendor to provide the necessary maintenance support. As the Organisation continued to seek the POS vendor’s assistance for any system service issue, it was also not entirely clear to the parties concerned whether the POS vendor remained responsible for ensuring that the POS system server was updated or patched. It should be reiterated that while an organisation may engage other third-party service providers to provide the 2 necessary technical assistance and support, an organisation’s responsibility for complying with its statutory obligations under the PDPA may not be delegated.1 Given the Organisation’s omission to engage any maintenance support prior the Incident, the Organisation bore full responsibility for its failure to conduct or schedule the necessary software updates, patches and security reviews. 4. In the circumstances, the Organisation is found to have breached section 24 of the Personal Data Protection Act 2012 (the “PDPA”). 5. After the preliminary decision was issued, the Organisation submitted representations requesting for a waiver of the financial penalty imposed. The Commission considered the representations made, and took into account first, the remediation efforts taken by the Organisation since the Incident, and its commitment to invest in a better and more secure IT system, and second, the adverse impact the COVID-19 pandemic had on the Organisation’s business revenue. Nonetheless, as explained above, the onus remained on the Organisation to put in place adequate security measures such as regular IT system maintenance, patches and periodic security reviews. . 6. Having considered all the circumstances in this case, the Deputy Commissioner directs that the Organisation pays a financial penalty of S$5,000 within 30 days from the date of the notice accompanying this decision, failing which interest at the rate specified in the Rules of Court in respect of judgment debts shall accrue and be payable on the outstanding amount of such financial penalty until the financial penalty is paid in full. 7. Finally, having considered the remedial actions taken by the Organisation, the Commission will not issue any directions under section 48I of the PDPA. 1 See Re WTS Automotive Services Pte Ltd [2019] PDP Digest 317 at [14] and [23]. 3 The following is the provision of the Personal Data Protection Act 2012 cited in the above summary: Protection of personal data 24. An organisation shall protect personal data in its possession or under its control by making reasonable security arrangements to prevent – (a) unauthorised access, collection, use, disclosure, copying, modification, disposal or similar risks; and (b) the loss of any storage medium or device on which personal data is stored. 4 ",Financial Penalty,ba5645fa0a7e61666bb1148c1c65700478353304,"[""tags"",""decision"",""pdf-url"",""description"",""date"",""timestamp"",""url"",""title"",""nature"",""pdf-content""]" 2023-10-01T11:02:10+08:00,fbd32491db44d3d0c97aa12a99cefd61ec954264,33,33,1,1016,"A financial penalty of $12,500 was imposed on PINC for failing to put in place reasonable security arrangements to protect the personal data in its possession. Directions were also issued to PINC to develop and implement internal data protection policies and practices to comply with the PDPA and to ensure no copies of database were stored on employees' personal computers.","[""Accountability"", ""Protection"", ""Financial Penalty"", ""Directions"", ""Wholesale and Retail Trade"", ""No Policy""]",2022-05-19,https://www.pdpc.gov.sg/-/media/Files/PDPC/PDF-Files/Commissions-Decisions/Decision---PINC-Interactive-Pte-Ltd---04022022.pdf,"Accountability, Protection",Breach of the Accountability and Protection Obligations by PINC Interactive,https://www.pdpc.gov.sg/all-commissions-decisions/2022/05/breach-of-the-accountability-and-protection-obligations-by-pinc-interactive,2022-05-19,"PERSONAL DATA PROTECTION COMMISSION [2022] SGPDPC 1 Case No. DP-2002-B5827 In the matter of an investigation under section 50(1) of the Personal Data Protection Act 2012 And PINC Interactive Pte. Ltd. … Organisation DECISION Page 1 of 9 PINC Interactive Pte. Ltd. [2022] SGPDPC 1 Lew Chuen Hong, Commissioner — Case No. DP-2002-B5827 4 February 2022 Introduction 1 On 2 February 2020, the Personal Data Protection Commission (“the Commission”) received feedback about a Twitter post dated 31 January 2020 which revealed that the personal data of users of www.pincstyle.com had been exposed. The tweet included a snapshot of the data (“the Incident”). The Commission commenced investigations into the Incident thereafter. Facts of the Case 2 The website www.pincstyle.com was created and managed by PINC Interactive Pte. Ltd. (“the Organisation”) at the material time. Investigations revealed that sometime in October 2019, a database comprising 252,813 records was accessed and exfiltrated from the Organisation’s staging servers (the “Staging Database”). The Staging Database is a synthetic database containing personal data of 3,916 actual users, while the remaining 248,897 records were fake or “dummy” data modelled after the real data. The synthetic database was used to facilitate development and testing on the staging servers. The personal data from the 3,916 actual users that were exposed in the Incident included the name, username, email address, contact number (for some users) and a password hash. For completeness, the 3,916 user records in the Staging Database is equivalent to 1.6% of the Organisation’s total database of 252,813 user records. Page 2 of 9 3 Investigations revealed two likely causes of the Incident. First, the developers, who are the Organisation’s employees, had retained a copy of the Staging Database on their own personal devices, and the database was exfiltrated when the developers’ computers were compromised. The Organisation stated that while they had instructed the developers to use strong passwords, the developers were left to manage the security settings on their own computers, and only had antivirus software installed. 4 Second, unauthorised access may have occurred from May 2019 to October 2019 when the Organisation did not require authentication for the Application Programming Interface (“API”) under testing (“Staging API”), which pointed to the Staging Database containing the personal data of real users, despite the Staging Database being accessible over the Internet. The Organisation only implemented access key authentication from October 2019 onwards. Remedial actions 5 Following the Incident, the Organisation took the following remedial actions: a. Updated the API with new authentication keys; b. Limited the access of authentication keys to only the senior developers; c. A password reset was initiated for affected users via email; and d. Developers were instructed to delete their local copy of the Staging Database and scan their own computers for malware. Findings and Basis for Determination Whether the Organisation contravened the Protection Obligation 6 Section 24 of the Personal Data Protection Act 2012 (“PDPA”) requires an organisation to protect personal data in its possession or under its control by making reasonable security arrangements to prevent unauthorised access, collection, use, Page 3 of 9 disclosure, copying, modification, disposal or similar risks (the “Protection Obligation”). For the reasons set out below, the Organisation failed to implement reasonable security arrangements to protect the personal data in the Staging Database. 7 Firstly, the Organisation had failed to accord adequate protection to the personal data by allowing their employees, i.e. the developers, to store local copies of the Staging Database in their own personal devices, without implementing any additional security requirements. Allowing their employees to store the Staging Database in their own personal devices constituted a breach of the Protection Obligation, given that the Staging Database did not merely contain purely synthetic data, but also the personal data of real users. 8 Secondly, the Organisation was also in breach of the Protection Obligation as it merely instructed its employees not to use weak passwords on their personal devices, and left it to each individual employee to decide if and what level of security measures ought to be implemented on their own personal devices to protect the personal data. Indeed, even though the developers had purportedly installed antivirus software on their own personal devices, the Organisation was unable to provide the product name, version, or the frequency of the antivirus updates that the developers supposedly implemented on their end when questioned. 9 In Learnaholic Pte. Ltd.1, the Organisation was found in breach of section 24 of the PDPA as the personal data affected had been sent to and stored in the work email account belonging to the Organisation’s representative in an unencrypted form. After completing the task at hand, the representative failed to delete the email containing the personal data that he received. Instead, the representative kept the email containing the personal data, in case he needed it in future. As a result, the hacker had free rein to the personal data affected once he obtained access to the email 1 [2019] SGPDPC 31. Page 4 of 9 account. In a similar vein, the Organisation here has failed to adopt adequate security measures when it simply allowed its employees to retain a copy of the Staging Database on their own personal devices, without putting any thought to the security measures that ought to be implemented to protect the personal data. 10 Finally, while we appreciate that the Organisation wanted the Staging API to mirror the production environment, it was not a reasonable “protection” measure to commingle synthetic data with the personal data belonging to real users, without processing the personal data of the real users before doing so, as this meant that the Staging Database contained the data of real users. Having decided to use personal data belonging to real users in the Staging Database, the Organisation has breached the Protection Obligation by failing to require authentication before the Staging API could be accessed. If the Organisation’s intention was not to require authentication for the Staging API, the Organisation should have chosen to use only synthetic data in the Staging Database. In How to Guard Against Common Types of Data Breaches (the “Handbook”),2 the Commission identified the five most common gaps in ICT system management and processes, and observed at page 11 of the Handbook that: “Out of convenience, many organisations use production data for system testing in their test environments. But as test environments tend to be much less secured, there is a high risk of data breach in a test environment.” 11 In the Handbook, the Commission explained that synthetic data can be generated either from scratch using commercial tools or by anonymising production data, and recommended that organisations can create synthetic data (i.e. fake personal data or data anonymised from real data) for development and testing purposes in non-production environments instead of using real data. 2 https://www.pdpc.gov.sg/news-and-events/announcements/2021/05/handbook-on-how-to-guard- againstcommon-types-of-data-breaches-now-available Page 5 of 9 12 In this case, the Organisation could have chosen to use 100% synthetic data or anonymise the personal data before using them if it did not wish to require authentication for the Staging API. In light of the above, we are also of the view that the Organisation breached the Protection Obligation by using personal data belonging to real users in the Staging Database, but failing to require authentication before the Staging API could be accessed. Whether the Organisation contravened the Accountability Obligation 13 Section 12(a) of the PDPA requires an organisation to develop and implement policies and practices that are necessary for the organisation to meet its obligations under the PDPA (the “Accountability Obligation”). 14 The Organisation admitted that they did not have any data protection policies or practices in place for their “non-technical” employees, who have access to “public user data”. In its reply, the Organisation drew a distinction between its “technical” and “non-technical staff”, and stated that for the “technical” staff, the data protection policies in place extended to the Organisation’s team lead providing a briefing to the “technical” staff of the system, rules for branch creation and the code standard during onboarding. The information provided by the Organisation to its “technical” staff, during their onboarding, serves merely to facilitate the performance of these employees’ core duties, and cannot be equated with or amount to data protection policies or practices. 15 Indeed, the Organisation’s reply reflects a lack of understanding of what data protection policies and processes seek to achieve and implement. We have previously stressed the critical role that data protection policies and practices play in increasing awareness and ensuring accountability of an organisation’s obligations under the PDPA in Re Aviva Ltd3. We also explained in Re Singapore Cricket Association4 that data protection policies and practices ensure that employees will be able to better 3 [2018] PDP Digest 245 at [32]. 4 [2019] PDP Digest 270 at [19]. Page 6 of 9 protect personal data when they are first able to recognise a matter as one involving data protection. 16 Given the Organisation’s reply, it follows that the Organisation did not in fact have any data protection policies or processes in place to guide their employees on how to comply with the PDPA in carrying out their work functions. The Organisation has therefore breached the Accountability Obligation. The Commissioner’s Directions 17 In determining whether to impose a financial penalty on the Organisation pursuant to section 48J(1) of the PDPA, and if so, the amount of such financial penalty, the factors listed at section 48(6) of the PDPA were taken into account, as well as the following aggravating and mitigating factors: Aggravating Factors (a) The Organisation allowed its employees to keep local copies of the Staging Database on their personal devices, without considering and undertaking any security measures needed to protect the personal data of real users; Mitigating Factors (b) The Organisation was cooperative in the course of investigations and had provided prompt responses to PDPC’s requests for information; and (c) The Organisation was implemented remedial actions to address the Incident. 18 In the course of settling this decision, the Organisation made representations on the amount of financial penalty that the Commissioner intended to impose. Page 7 of 9 The Organisation raised the following factors for the Commissioner’s consideration: (a) The Organisation had engaged an external consultancy firm to ensure that its obligations under the PDPA are upheld to the highest standards with periodic audits, training and risk assessments; and (b) The Organisation was incorporated in 2018 and is still a relatively young company. Since its inception, it had been suffering significant losses in its operation. 19 Having considered the Organisation’s representations, as well as all the relevant factors of this case, the Commissioner hereby decided to impose a reduced financial penalty of $12,500 on the Organisation. The quantum of financial penalty has been calibrated and reduced after due consideration of the Organisation’s financial circumstances, bearing in mind that any financial penalty imposed should not be crushing or cause undue hardship on organisations. 20 Taking into account all the relevant facts and circumstances, the Commissioner hereby: (a) Requires the Organisation to pay a financial penalty of $12,500 within 30 days from the date of the relevant notice accompanying this decision, failing which interest at the rate specified in the Rules of Court in respect of judgment debts shall accrue and be payable on the outstanding amount of such financial penalty until the financial penalty is paid in full; (b) Directs the Organisation to: (i) Develop and implement internal data protection policies and practices to comply with the PDPA within 60 days of the relevant direction accompanying this decision; Page 8 of 9 (ii) Ensure that no local copies of the database are stored on the personal computers of any employees (including both developers and senior developers) within 60 days of the relevant direction accompanying this decision; and (iii) To notify the Commission within 1 week of the completion of this direction. 21 Although the Commissioner has imposed a lower financial penalty on the Organisation in this case, the financial penalty was arrived at after considering the dismal state of the Organisation’s finances, and should be confined to the specific facts of this case. YEONG ZEE KIN DEPUTY COMMISSIONER FOR COMMISSIONER FOR PERSONAL DATA PROTECTION Page 9 of 9 ","Financial Penalty, Directions",d2cda7ac80cc4638223955ef382304ee06a36b98,"[""tags"",""decision"",""pdf-url"",""description"",""date"",""timestamp"",""url"",""title"",""nature"",""pdf-content""]" 2023-10-01T11:02:10+08:00,fbd32491db44d3d0c97aa12a99cefd61ec954264,34,34,1,1016,"A financial penalty of $24,000 was imposed on Lovebonito for failing to put in place reasonable security to protect personal data in its possession. The incident resulted in the personal data being accessed and exfiltrated.","[""Protection"", ""Financial Penalty"", ""Wholesale and Retail Trade"", ""Password policy""]",2022-05-19,https://www.pdpc.gov.sg/-/media/Files/PDPC/PDF-Files/Commissions-Decisions/Decision--Lovebonito-Singapore-Pte-Ltd--21022022.pdf,Protection,Breach of the Protection Obligation by Lovebonito,https://www.pdpc.gov.sg/all-commissions-decisions/2022/05/breach-of-the-protection-obligation-by-lovebonito,2022-05-19,"PERSONAL DATA PROTECTION COMMISSION [2022] SGPDPC 3 Case No. DP-1912-B5484 In the matter of an investigation under section 50(1) of the Personal Data Protection Act 2012 And Lovebonito Singapore Pte. Ltd. … Organisation DECISION Lovebonito Singapore Pte. Ltd. [2022] SGPDPC 3 Lew Chuen Hong, Commissioner — Case No. DP-1912-B5484 21 February 2022 Introduction 1 On 12 December 2019, Lovebonito Singapore Pte. Ltd (the “Organisation”) informed the Personal Data Protection Commission (“Commission”) that one of its IT systems had been hacked, and that the personal data of 5,561 of its customers had been accessed and exfiltrated by a malicious actor (the “Incident”). The Commission subsequently received two separate complaints from individuals affected in the Incident. Facts of the Case 2 The Organisation operates an e-commerce platform (the “Website”) retailing clothing and accessories. At the material time, the Organisation employed, amongst others, two third-party solutions to manage the Website. First, the Organisation employed Magento Cloud, a cloud-based service, to host and run the Website. Magento Cloud includes the Magento Content Management System (“Magento CMS”), an open-source e-commerce management software, which the Organisation used to change and update the Website. Second, the Organisation used a payment platform offered by Adyen N.V. (“Adyen”) to facilitate credit card payments on the Website. When a customer indicated that they intended to pay for their purchases via credit card, Adyen’s platform would load directly from their servers as a frame within the “checkout” page of the Website (the “Checkout Page”). 3 Customers would then input the below details into Adyen’s frame, and Adyen would directly collect these details and process the credit card payment: (a) Full credit card number; (b) Expiry date of the credit card; 2 (c) The CVV number of the credit card; and (d) Customer’s billing address (collectively, the “Credit Card Data”) 4 Once Adyen has processed the credit card payment, it would send some (but not all) of the Credit Card Data to the Organisation, namely: (a) The last 4 digits of the credit card number; (b) Expiry date of the credit card; (c) Adyen’s payment reference; and (d) Billing address. (collectively, the “Partial Credit Card Data”) 5 The Organisation would then store the Partial Credit Card Data together with other details collected by the Organisation for the purposes of processing the order (the “Order Data”). The Order Data comprised the following personal data of the Organisation’s customers: (a) First name; (b) Last name; (c) Shipping address; (d) Date of birth (optional); (e) Phone number; (f) Email address; (g) Order details; (h) Payment type: Paypal, credit card (i.e., Visa, Mastercard), bank transfer; and 3 (i) If payment was made via: (i) Credit Card: Partial Credit Card Data; or (ii) Paypal: the email address associated with the Paypal account (if the customer in question completed the transaction using his/her Paypal account). 6 On or around 22 November 2019, the Organisation noted a high drop in credit card authorisations for payments via Adyen’s platform and began investigating the issue with Adyen. It was discovered that the Checkout Page had been configured to load an incorrect form replacing Adyen’s frame on the Checkout Page. This incorrect form had not been submitted via Magento CMS or validated by any of the Organisation’s employees, and the Organisation was unable to determine the source of the form. The next day, the Organisation implemented a fix to replace the incorrect form with the correct one, in order to allow the processing of credit card payments to resume through Adyen’s platform, while root cause analysis was undertaken. 7 Subsequently, on or around 9 December 2019, the same issue resurfaced. As a precaution, the Organisation turned off the credit card payment functionality on the Checkout Page, and continued investigations into the issue with Adyen, Magento, and subsequently a private forensic investigator (“PFI”). 8 Based on these further investigations, it was concluded that: (a) One of the Organisation’s Magento CMS accounts with administrator privileges was likely to have been compromised (the “Compromised Account”); (b) The Compromised Account was likely used to modify the Checkout Page to load and execute an unauthorised JavaScript code each time the Checkout Page was loaded (“the Unauthorised Code”); (c) The Unauthorised Code caused the Credit Card Data intended to be sent to Adyen to be intercepted and exfiltrated to the malicious actor instead (explaining the drop in credit card transactions); and 4 (d) The Compromised Account was also used by the malicious actor to access and exfiltrate Order Data from the Website via unauthorised Application Programming Interface (“API”) calls to Magento CMS. 9 The personal data of a total of 5,561 customers was accessed and exfiltrated in the Incident of which: (a) 4,817 customers had only their Order Data affected; (b) 188 customers had only their Credit Card Data affected: and (c) 556 customers had both their Order Data and Credit Card Data affected. Remedial actions 10 Following the Incident, the Organisation: (a) Removed the Unauthorised Code from the Website; (b) Notified affected customers of the Incident and offered a complimentary credit monitoring service; (c) Reset the passwords for all Magento CMS user accounts; (d) Implemented a new password policy and two-factor authentication for all Magento CMS user accounts; (e) Implemented session management; (f) Reviewed its Magento CMS access permissions, refined the scope of roles, and limited the number of users with Magento CMS accounts; (g) Implemented a remote access virtual private network; (h) Implemented endpoint protection; (i) Implemented a custom script to monitor for JavaScript injections; (j) Set up API “whitelisting” to restrict network access to only approved IP addresses; 5 (k) Implemented a monitoring script to trigger alerts whenever there was a request from a non-trusted domain; (l) Conducted two external penetration tests; (m) Upgraded its version of Magento CMS to fix a security vulnerability found in the version it was using; and (n) Implemented CAPTCHA on its Website to deter brute-force attacks. Findings and Basis for Determination 11 As a preliminary point, both the Order Data and the Credit Card Data constituted personal data as defined by section 2(1) of the Personal Data Protection Act 2012 (“PDPA”) 1 . In respect of the Order Data, distinct individuals could be identified from such data. In respect of the Credit Card Data, although such data could not identify any individual on its own, it could identify individuals together with other data that the Organisation had access to (viz., the Order Data). Whether the Organisation had contravened section 24 of the PDPA 12 Section 24 of the PDPA requires an organisation to protect personal data in its possession or under its control by making reasonable security arrangements to prevent unauthorised access, collection, use, disclosure, copying, modification, disposal or similar risks (the “Protection Obligation”). While the Organisation did not have possession of the Credit Card Data (i.e. because it did not collect or store the Credit Card Data), the Protection Obligation nonetheless applied, as it had control over the Credit Card Data. 13 As highlighted in Re AIG Pacific Insurance Pte. Ltd. [2018] SGPDPC 8 at [18]: “While there is no definition of “control” in the PDPA, the meaning of control in the context of data protection is generally understood to cover the ability, 1 Under section 2(1) of the PDPA, “personal data” is defined as “data, whether true or not, about an individual who can be identified (a) from that data; or (b) from that data and other information to which the organisation has or is likely to have access”. 6 right or authority to determine (i) the purposes for; and/or (ii) the manner in which, personal data is processed, collected, used or disclosed.” 14 In this case, the Organisation made the decision to deploy Adyen’s HTML code within a frame on the Checkout Page, and this decision directed the manner in which the Credit Card Data was collected, processed and disclosed via the Website. Thus, even though the Credit Card Data was sent to Adyen directly without first being collected and stored by the Organisation, the Organisation had control over how the Credit Card Data was collected, and the additional processing into a format which was then transmitted to Adyen. The Organisation exercised such control by implementing (or deploying) Adyen’s HTML code within a frame on its Checkout Page. 15 The application of the Protection Obligation to the Order Data is more straight forward as this dataset was collected and stored by the Organisation. As the Organisation had possession of the Order Data and control over the Credit Card Data, the Protection Obligation applied in respect of both datasets. 16 In assessing the reasonableness of the Organisation’s security arrangements, the fact that the data within its control included personal data of a financial nature (i.e. the Credit Card Data) was considered highly relevant. As highlighted in the Commission’s previous enforcement decisions, stronger security measures are called for when protecting sensitive personal data because of the potential harm that may befall an individual from unauthorised use of such data.2 17 For the reasons set out below, the Organisation failed to put in place such reasonable security arrangements to protect the Order Data and Credit Card Data. Inadequate password policy 18 A robust password policy is a key security measure that an organisation must have in place to ensure that its IT systems are not vulnerable to common hacking attempts such as brute force attacks. As noted in Re (1) The Cellar Door Pte Ltd; (2) Global Interactive Works Pte. Ltd. [2016] SGPDPC 22 (at [30(d)]): 2 Credit Counselling Singapore [2017] SGPDPC 18 at [25]; PeopleSearch Pte. Ltd. [2019] SGPDPC 47 at [10]. 7 “… The need to have a strong password is fundamental to the security of the database system. Weak passwords increase the chances of an intruder cracking the password and gaining full access to the database system, and, more importantly, the personal data stored therein.” 19 Magento CMS had several default security settings and the Organisation confirmed that it had adopted these default settings as its password policy for its Magento CMS accounts (the “Magento Password Policy”). While default settings of the Magento Password Policy on password length, and the implementation of a lockout after a number of failed login attempts were in line with good practices suggested in the Commission’s Guide to Securing Personal Data in Electronic Medium (the “Guide”)3, more robust and stringent measures were required. 20 First, the Magento Password Policy did not mandate periodic changes of passwords as part of the default settings, despite the availability of this functionality in Magento CMS. As stated in paragraph (g) of Table 4 in the Guide: “Users are required to change their passwords regularly. The frequency should be based on the risk of damage to the individual if the data is compromised.” [Emphasis added.] 21 Second, the default settings of the Magento Password Policy did not require the Organisation’s employees to refrain from using easily-guessable passwords. As highlighted in Re Chizzle Pte Ltd [2020] SGPDPCR 1, a password that complies with an organisation’s rules on password complexity in form, could still be regarded as a weak password if it incorporated components such as the organisation’s name. In this respect, the Organisation ought to have complemented the technical Magento Password Policy with a written password policy. Both written and technical policies reinforce each other. Technical policies alone may not ensure that users refrain from incorporating easily-guessable words or phrases such as their user name, real name, 3 Published on 8 May 2015, and revised on 20 January 2017. The Guide has recently been replaced by a new Guide to Data Protection Practices for ICT Systems. All references to the Guide in these grounds are to the 2017 edition. 8 birth date, or the organisation’s name in the password. In this case, the password of the Compromised Account – “ilovebonito88” – incorporated the Organisation’s name, which made it easy to guess and vulnerable to brute force attacks. 22 For these reasons, the out-of-the-box default settings of the Magento Password Policy was not sufficiently robust for the Organisation’s needs and failed to meet the standard of being a reasonable security arrangement under the Protection Obligation. Weaknesses in the Organisation’s host, network, remote access, and webpage security 23 There were other significant weaknesses in the Organisation’s IT systems identified by the PFI that could have also been exploited by malicious actors to gain privileged access to Magento CMS: (a) The Organisation’s system allowed insecure remote access, with no / limited system logging and no / limited system hardening; (b) The Organisation’s system was not patched / maintained; (c) There was a lack of security monitoring for the Organisation’s network; (d) There was a lack of network ingress and egress filtering of the Organisation’s network to examine network traffic; (e) There was a lack of monitoring and logging of remote access connection attempts; and (f) 24 There was improper access control in respect of Magento CMS. The above weaknesses indicated that the IT security measures implemented by the Organisation were inadequate in managing the risks of unauthorised access and exfiltration of the Credit Card Data and Order Data. 25 The above security measures did not meet the standard of reasonableness, and the Commissioner finds the Organisation in breach of the Protection Obligation in this regard. 9 The Preliminary Decision 26 In determining whether to impose a financial penalty on the Organisation pursuant to section 48J(1) of the PDPA, and if so, the amount of such financial penalty, the factors listed at section 48J(6) of the PDPA were taken into account, as well as the following mitigating factors: Mitigating Factors (a) The Organisation took prompt remedial actions following discovery of the Incident, including notifying affected individuals of the breach; and (b) 27 The Organisation was cooperative during the investigations. In the preliminary decision, the Organisation’s failure to implement two-factor authentication (“2FA”) to secure privileged access to Magento CMS was also considered as an instance of breach of the Protection Obligation – this is discussed further below at [33] to [36]. Having considered all the relevant factors of this case, the preliminary financial penalty was set at $29,000. 28 The Organisation was notified of the preliminary decision by way of the Commission’s letter dated 21 June 2021 and was invited to make representations on the same. Representations Made by the Organisation 29 On 12 July 2021, the Organisation made representations that it ought not be found in breach of section 24 of the PDPA because: (a) The Organisation’s measures to safeguard its administrative accounts were reasonable; and (b) It could not be conclusively determined that the weaknesses in the Organisation’s IT systems had directly caused the Incident. 10 Representations on reasonableness of security measures for Magento CMS 30 The Organisation represented that its security measures for Magento CMS were commensurate with the risks associated with a potential data breach, as: (a) Magento CMS was only intended to collect and store the Order Data, which was less sensitive personal data; and (b) The risk of compromise to the more sensitive Credit Card Data via Magento CMS was assessed to be relatively low, where the Credit Card Data was collected directly by Adyen via a frame on the Website’s Checkout Page loaded directly from Adyen’s server, without such data being transmitted to the Organisation. 31 The Organisation’s representations in this regard are not accepted. While it is accepted that the Credit Card Data was not transmitted to the Organisation and was collected directly by Adyen via the Checkout Page of the Website, access and changes to the Website were in turn managed and carried out by the Organisation via Magento CMS. There was therefore a foreseeable risk that unauthorised access to the Website using one of the Organisation’s Magento CMS administrative accounts could lead to unauthorised changes to the Checkout Page, adversely affecting its intended function and performance. Such unauthorised changes could include the insertion of a malicious code to intercept and exfiltrate the Credit Card Data collected via the Checkout Page. 32 The Credit Card Data was collected via the Website, and it was for the Organisation to secure the Website against unauthorised changes in order to protect the Credit Card Data. Put differently, the Organisation’s Protection Obligation extended over the Website in its entirety, including the Checkout Page. The Organisation was therefore incorrect in assessing that there was a low risk of compromise to the Credit Card Data via Magento CMS. The security measures implemented by the Organisation for Magento CMS and in its databases and systems did not constitute reasonable security measures, having regard to the risks in the context of the sensitivity and volume of the personal data in its possession and/or control. 11 Representations on failure to enable 2FA for administrative accounts 33 In the present case, 2FA was available as an “out-of-the-box” feature in Magento CMS. In the preliminary decision, the Organisation’s failure to enable 2FA in Magento CMS was found to be another instance of its breach of the Protection Obligation. 34 The Organisation represented that 2FA was not an out-of-the-box feature in Magento CMS version 2.3.2, which the Organisation was using at the time of the Incident, and that the option to activate 2FA was only available in Magento CMS version 2.4, via a third-party vendor (GitHub) module “MSP_TwoFactorAuth”. However, according to publicly available Magento version 2.3.x user guides – and contrary to the Organisation’s representations – 2FA was already a feature available on Magento CMS version 2.3.2, albeit at that version, 2FA was not enabled by default. 35 The Organisation also represented that even if 2FA had been implemented, it would not have prevented the Incident as the “2FA functionality in Magento CMS version 2.4 would only have restricted unauthorised access via the graphical user interface (“GUI”) of Magento CMS” and that “(…) 2FA would not have prevented API calls to Magento CMS, which was the actual mechanism by which the Organisation’s website was modified during the Incident”. In an investigation summary report prepared by Magento in respect of the Incident, Magento did not find any evidence of changes made to the Organisation’s website made via the GUI, and concluded that it was “more likely” that the administrative account belonging to [redacted] was used “to make modifications and access information via API requests”. 36 After careful consideration of the Organisation’s representation, it is decided that the benefit of doubt ought to be given to the Organisation on the preliminary findings and its representations concerning the implementation of 2FA for two reasons. First, the external actor accessed and modified the Organisation’s Website via API calls to Magento CMS (as opposed to via the GUI of Magento CMS), which made the attack a sophisticated one. Second, the Organisation’s failure to consider enabling the out-of-the-box 2FA functionality within Magento CMS was but one of several instances 12 supporting the finding of its breach of the Protection Obligation. The finding of breach is maintained on the basis of other instances of breach. Representations on other weaknesses in IT systems 37 The Organisation’s representation that it cannot be conclusively determined that the weaknesses in its IT systems had directly caused the Incident (see [29(b)] above) is rejected. The Commission’s role is not limited to investigating the immediate or proximate cause of the data breach although this may have been one of the lines of inquiry. The Commission’s investigations found that other weaknesses in the Organisation’s IT systems posed risks to personal data in the Organisation’s possession and/or control, including Order Data that it collected and processed. The Organisation ought to have implemented reasonable security measures to manage these risks. In failing to do so, the Organisation breached the Protection Obligation. Other representations seeking reduction in financial penalty 38 The Organisation also made representations for a reduction in the financial penalty on the basis that: (a) It was inaccurate to state the number of affected individuals as 5,561, as only 4,474 individuals in Singapore were affected; (b) The Organisation had admitted to the Incident at first instance; (c) The Organisation had promptly alerted customers of the Incident and offered a complimentary credit monitoring service; (d) There were no other data breach incidents reported apart from the Incident; and (e) The Organisation had in place existing security measures to guard against unauthorised access to databases and systems. 39 The Organisation’s attempt to confine the number of affected individuals in the Incident to those in Singapore is misconceived and is rejected. The PDPA requires organisations to protect all personal data in their possession or control, and does not 13 draw distinctions between the personal data of individuals in Singapore and outside of Singapore. 40 As to the factors raised by the Organisation at [38(b)] to [38(e)] above, these had already been taken into account in the assessment of the appropriate financial penalty to be imposed. 41 In the preliminary decision, the preliminary financial penalty was derived considering, inter alia, the gravity of the Organisation’s breach of the Protection Obligation in failing to consider implementing 2FA, which was available out-of-the-box. As the Organisation’s representations that 2FA may not have prevented the Incident are accepted, the gravity of the Organisation’s breach is lessened, and it follows that the quantum of the financial penalty should also be moderated. 42 Having said that, the Organisation’s breach included more fundamental failures, such as failing to implement a robust password policy and to refrain the Organisation’s employees from using easily-guessable passwords. Regardless of whether 2FA would have prevented the specific vector of attack adopted by the threat actor, the harm caused to data subjects in the Incident remains the same. 43 For the above reasons, the Commissioner is of the view that based on the representations made by the Organisation, the preliminary financial penalty of $29,000 should be reduced to $24,000. The Commissioner hereby requires the Organisation to pay a financial penalty of $24,000 within 30 days from the date of the notice accompanying this decision, failing which interest at the rate specified in the Rules of Court in respect of judgment debts would accrue and be payable on the outstanding amount of such financial penalty until the financial penalty is paid in full. 44 In view of the remedial actions already been taken by the Organisation, no further directions need be issued to the Organisation. 14 Two- or multi-factor authentication as mandatory baseline standard for administrative accounts with privileged access to systems that host or process sensitive personal data 45 As 2FA and multi-factor authentication (“MFA”) become more broadly available, the adoption of these tools should become the norm, at least for accounts with administrative privileges. 46 Recently, the Commission released a handbook on common causes of data breaches (How to Guard Against Common Types of Data Breaches4, at page 13) that recommends 2FA / MFA for all administrator access to systems holding large volumes / sensitive personal data: “Have stronger requirements for some administrative accounts (e.g. a complex password or 2-Factor Authentication (2FA) / Multi-Factor Authentication (MFA)). With 2FA/MFA in place, access to administrative accounts would involve additional round (s) of authentication, such as a temporary code sent securely to the administrator’s mobile phone. Hence, the use of a stolen password alone will not be enough to breach an account. This is important for administrative accounts to systems that hold large volumes of personal data, or personal data of a confidential or sensitive nature (e.g. financial or health records), where a breach of such data could result in adverse impact to the affected individuals.” [Emphasis added] 47 The Commission’s recent Guide to Data Protection Practices for ICT Systems5 at page 16 similarly recommends using “a one-time password (“OTP”) or 2FA/MFA for admin access to sensitive personal data records or large volumes of personal data”, as part of the authentication and authorisation processes in ICT systems. 4 https://www.pdpc.gov.sg/-/media/files/pdpc/pdf-files/resource-for-organisation/how-to-guard-againstcommon-types-of-data-breaches-handbook.pdf 5 https://www.pdpc.gov.sg/-/media/Files/PDPC/PDF-Files/Other-Guides/Tech-Omnibus/How-toGuard-Against-Common-Types-of-Data-Breaches-Handbook.pdf 15 48 This is the baseline standard that the Commission will apply in future cases. This is not a standard that was adopted lightly, but after industry consultation and considering developments domestically and internationally. 49 In recent domestic cases, the Commission has observed that 2FA was implemented by the Organisations involved as part of voluntary remedial measures: (a) In MSIG Insurance (Singapore) Pte Ltd and Globalsign.in Pte Ltd [2019] SGPDPC 43, an administrative account for the organisation’s email marketing system was hacked, resulting in spam emails being sent to over 350,000 individuals. The organisation was found in breach of the Protection Obligation for not implementing a proper password policy or carrying out periodic security scanning. As part of voluntary remedial measures, the organisation implemented 2FA for its administrative accounts. (b) In Ncode Consultant Pte Ltd [2019] SGPDPC 11, students exploited vulnerabilities in a school’s administration system (which had been developed by the investigated organisation), obtained a teacher’s login credentials, and modified examination results. The organisation was found in breach of the Protection Obligation for insecure coding which resulted in the exploited vulnerabilities. As part of voluntary remedial measures, the organisation implemented 2FA for the teachers’ accounts. (c) In Learnaholic Pte Ltd [2019] SGPDPC 31, an employee of the investigated organisation (a school IT vendor) had his email account hacked, resulting in unauthorised access to a large number of students’ personal data including medical information. The organisation was found in breach of the Protection Obligation for negligently leaving one of the school’s servers exposed to the Internet, leaving credentials to the employee’s email account in the exposed server, and storing students’ personal data in the employee’s email account in an unencrypted form. The organisation implemented 2FA for its employees’ email accounts as part of voluntary remedial measures. 16 50 A review of guidance and cases from foreign jurisdictions shows that implementing 2FA (or similar arrangements) to secure privileged access to sensitive data is by now a reasonable and industry-standard practice: (a) United Kingdom. In two separate guidance notes, i.e. “Multi-factor authentication for online services”6 and “10 Steps to Cyber Security – Identity and access management”7, UK’s National Cyber Security Centre advises that MFA be enabled for all accounts with administrative privileges. (b) Canada. The Privacy Commissioner of Canada (“PCC”) has cited the failure to implement MFA to secure all remote administrative access as a significant data protection failing in the Joint Investigation of Ashley Madison by the Privacy Commissioner of Canada and the Australian Privacy Commissioner/Acting Australian Information Commissioner 8 , where the personal data of 36 million customers of the investigated organisation (including sensitive personal and financial data) was published online. In a subsequent note on takeaways from the investigation 9 , the PCC described MFA as a commonly recommended industry practice for controlling remote administrative access, and recommended that MFA be so implemented in all such cases. (c) Australia. The “Australian Government Information Security Manual”, a cybersecurity framework for organisations published by the Australian Cyber Security Centre 10 , recommends that MFA be used to authenticate all (i) privileged users, (ii) positions of trust, (iii) users of remote access solutions, and (iv) users with access to important data repositories. The Office of the Australian Information Commissioner, in its “Guide to securing personal information”11 recommends that MFA be employed in circumstances that may 6 https://www.ncsc.gov.uk/guidance/multi-factor-authentication-online-services 7 https://www.ncsc.gov.uk/collection/10-steps/identity-and-access-management 8 Joint Investigation of Ashley Madison by the Privacy Commissioner of Canada and the Australian Privacy Commissioner/Acting Australian Information Commissioner (PIPEDA Report of Findings #2016-005, 22 August 2016) 9 https://www.priv.gc.ca/en/privacy-topics/business-privacy/safeguards-and-breaches/safeguardingpersonal-information/2016_005_ta/ 10 https://www.cyber.gov.au/acsc/view-all-content/guidance/authentication-hardening 11 https://www.oaic.gov.au/privacy/guidance-and-advice/guide-to-securing-personal-information/ 17 pose a higher security risk, such as remote access to a system or access to sensitive or restricted personal information. 51 Henceforth, the Commission adopts the following tiered approach: (a) First, 2FA / MFA should be implemented as a baseline requirement for administrative accounts to systems that hold personal data of a confidential or sensitive nature, or large volumes of personal data: see [46]-[47] above. Failure to do so can ipso facto amount to a breach, unless the organisation can show that its omission is reasonable or implementation of 2FA is disproportionate. (b) Second, remote access by privileged accounts to information systems that host confidential or sensitive personal data, or large volumes of personal data, should a fortiori be secured by 2FA / MFA. The risks concerning remote access are higher, thus the expectation to implement 2FA / MFA will correspondingly increase. (c) Third, organisations using IT systems to host confidential or sensitive personal data, or large volumes of personal data, are expected to enable and configure 2FA / MFA, if this is a feature that is available out-of-the-box. Omission to do so may be considered an aggravating factor. YEONG ZEE KIN DEPUTY COMMISSIONER FOR COMMISSIONER FOR PERSONAL DATA PROTECTION 18 ",Financial Penalty,89b55bd8d0fb6740006b25908bf6eba6b220b5c5,"[""tags"",""decision"",""pdf-url"",""description"",""date"",""timestamp"",""url"",""title"",""nature"",""pdf-content""]" 2023-10-01T11:02:10+08:00,fbd32491db44d3d0c97aa12a99cefd61ec954264,35,35,1,1016,Royal Caribbean Cruises (Asia) was found not in breach of the PDPA in relation to a coding error in a business software which resulted in emails containing personal data being sent to unintended recipients.,"[""Protection"", ""Not in Breach"", ""Arts, Entertainment and Recreation"", ""Software"", ""Unintended recipient""]",2022-05-19,https://www.pdpc.gov.sg/-/media/Files/PDPC/PDF-Files/Commissions-Decisions/Decision--Royal-Caribbean-Cruises-Asia-Pte-Ltd--130819.pdf,Protection,No Breach of the Protection Obligation by Royal Caribbean Cruises (Asia),https://www.pdpc.gov.sg/all-commissions-decisions/2022/05/no-breach-of-the-protection-obligation-by-royal-caribbean-cruises,2022-05-19,"PERSONAL DATA PROTECTION COMMISSION Case No. DP-1804-B1931 In the matter of an investigation under section 50(1) of the Personal Data Protection Act 2012 And Royal Caribbean Cruises (Asia) Pte. Ltd. SUMMARY OF THE DECISION 1. On 5 April 2018, the Personal Data Protection Commission (“Commission”) commenced investigation against Royal Caribbean Cruises (Asia) Pte Ltd (the “Organisation”) after receiving a complaint from a member of the public (the “Complaint”). The complainant stated that she had received the personal data of unrelated individuals in an email payment reminder sent by the Organisation. 2. Investigations revealed that, from 8 February 2018 to 4 April 2018, the personal data of 526 individuals were inadvertently disclosed to other unrelated members of the public via unintended email payment reminders (the “Data Breach Incident”). The personal data disclosed included booking IDs, ship codes, sailing dates, names, net amounts due, amounts paid, balance due and the balance due date (the “Affected Personal Data”). 3. The Organisation is part of the Royal Caribbean Group, and is the wholly owned subsidiary and data intermediary of the USA-based Royal Caribbean Cruises Ltd 1 (Liberia) (“RCL”). It is responsible for the following business functions on behalf of RCL: (a) Conducting sales and marketing activities on behalf of the cruise ship operators of the Royal Caribbean Group, including RCL; (b) Taking cruise bookings from Singapore-based customers of RCL; (c) Administering a loyalty membership programme on behalf of RCL; and (d) Collecting payments from Singapore-based customers of RCL who made their bookings via walk-in, roadshows and online bookings at the Royal Caribbean Group’s Singapore website. 4. RCL’s branch office in the Philippines (“RCL Philippines”) provides IT support to entities within the Royal Caribbean Group, and does not have a separate legal identity from RCL. On 1 January 2017, the Organisation entered into an operative intercompany agreement with RCL Philippines for the provision of IT support and customer services support. Such services included providing technical support for the business software applications and services used by the Organisation. 5. As part of its business functions, the Organisation would send its Singapore customers email payment reminders prior to the commencement of their cruises. On 8 February 2020, the Organisation automated this business function through a business software enterprise operated by RCL Philippines (the “Hyperion System”), which would generate pre-programmed emails to individual customers to remind them of outstanding bill amounts (the “Direct Payment Reminder”). Concurrently, a collated list of the customers (together with other personal data) who received the Direct Payment Reminder would be generated and sent via email 2 to the Organisation (“Collated Payment Reminder”). Both the Direct Payment Reminder and Collated Payment Reminder were automatically generated on a scheduled frequency and sent to the customers and Organisation by the Hyperion System without any manual intervention from the Organisation (the “Automated Payment Reminder System”). 6. The Automated Payment Reminder System had been successfully implemented in other countries, and RCL Philippines put in place the following process to handle requests from Royal Caribbean Group entities related to the Hyperion System: (a) RCL Philippines would receive a request from respective Royal Caribbean entity for a new process to be implemented in the Hyperion System; (b) RCL Philippines would review the scope of the request and configure the Hyperion System; (c) RCL Philippines would then run a test cycle and a test email would be generated to RCL Philippines to test for whether the content was in line with the request by the requesting Royal Caribbean entity; (d) Thereafter, RCL Philippines would send a sample of the output email to the relevant Royal Caribbean entity to review; and (e) The relevant Royal Caribbean entity would sign off on the implementation and RCL Philippines would then implement the new process to go live. 7. Investigations revealed that the Data Breach Incident occurred because RCL Philippines made an error in the coding of the email parameters in the Structured Query Language (“SQL”) script when configuring the Hyperion System as described in paragraph 6(b), leading to the Collated Payment Reminders being 3 sent to the first customers in the mailing lists instead of the Organisation. Consequently, the personal data of the Singapore customers contained in the Collated Payment Reminders were disclosed to certain unrelated customers. 8. Both the Organisation and RCL Philippines were not aware of this error until they were informed of the Complaint to the Commission referenced in paragraph 1. As the Automated Payment Reminder System was new and unfamiliar to the Organisation at the material time, the Organisation and its employees were also not aware that it was supposed to be receiving the Collated Payment Reminders. 9. The Data Breach Incident happened after the Organisation provided lists of Singapore customers with outstanding payments due to RCL Philippines for processing with the Hyperion System. The Commission is of the view that the coding error that occurred during the configuration of the Hyperion System was wholly within RCL Philippines’ operations and that the Data Breach Incident did not arise from any business functions that the Organisation was conducting as a data intermediary on behalf of RCL. 10. In the above circumstances, the Deputy Commissioner for Personal Data Protection finds that the Organisation was not in breach of the Protection Obligation under section 24 of the PDPA. 4 11. We note that the Organisation had taken the following remedial actions: (a) Conducted additional trainings for its employees to be mindful of the importance of data protection in its business processes; (b) Reviewed its supervisory framework for new employees so that similar incidents would not happen again; and (c) Reviewed its communication with RCL Philippines for implementation of any new processes. The following is the provision of the Personal Data Protection Act 2012 cited in the above summary: Protection of personal data 24. An organisation shall protect personal data in its possession or under its control by making reasonable security arrangements to prevent unauthorised access, collection, use, disclosure, copying, modification, disposal or similar risks. 5 ",Not in Breach,0d00bbb6002dda7ff71a02aa63df23ee41375297,"[""tags"",""decision"",""pdf-url"",""description"",""date"",""timestamp"",""url"",""title"",""nature"",""pdf-content""]" 2023-10-01T11:02:10+08:00,fbd32491db44d3d0c97aa12a99cefd61ec954264,36,36,1,1016,Singtel was found not in breach of the PDPA in relation to an incident which occurred on or about 20 January 2021 whereby threat actor(s) exfiltrated personal data by exploiting zero-day vulnerabilities of a third party file transfer appliance.,"[""Protection"", ""Not in Breach"", ""Information and Communications""]",2022-05-19,https://www.pdpc.gov.sg/-/media/Files/PDPC/PDF-Files/Commissions-Decisions/Decision---Singapore-Telecommunication-Limited---101221.pdf,Protection,No Breach of the Protection Obligation by Singapore Telecommunications (Singtel),https://www.pdpc.gov.sg/all-commissions-decisions/2022/05/no-breach-of-the-protection-obligation-by-singapore-telecommunications,2022-05-19,"PERSONAL DATA PROTECTION COMMISSION Case No. DP-2102-B7878 In the matter of an investigation under section 50(1) of the Personal Data Protection Act 2012 And Singapore Telecommunication Limited SUMMARY OF THE DECISION 1. On 10 February 2021, Singapore Telecommunication Limited (the “Organisation”) notified the Personal Data Protection Commission (the “Commission”) of a personal data breach that had occurred through the exploitation of zero-day vulnerabilities in a File Transfer Appliance (“FTA”) provided by a third party system (the “Incident”). 2. As a result of the Incident, 9,921 files containing personal data were exfiltrated. The personal data of 163,370 individuals which included their name, NRIC number, FIN, UIN, nationality, date of birth, address, email address, mobile number, photograph, staff, company pass or ID, bank account number, credit Page 1 of 3 card information (with expiry date), billing information, and vehicle number were affected. 3. The Organisation engaged an external cybersecurity company, FireEye Mandiant, to investigate the Incident. Its investigations found that the threat actors had exploited two (2) zero-day vulnerabilities of the FTA to gain unauthorised access to the FTA’s MySQL database and subsequent file downloading. 4. Investigations revealed that the Organisation had a license to use the FTA with the FTA developer, Accellion Pte Ltd (“Accellion”). Accellion was the only party that had access to the proprietary source code to the FTA system. Accordingly, the discovery and rectification of the zero-day vulnerabilities within the FTA system fell within the sole responsibility and control of the developer. We are of the view that the Organisation could not have detected or prevented the incident as it had no control or visibility of the zero-day vulnerability of the FTA. 5. The Organisation had provided and made reasonable security arrangements to protect personal data in its possession and/or control in relation to the Incident. The Organisation maintained the practice of updating and patching the FTA within five (5) days of patch/update receipt. 6. Following the Incident, the Organisation took prompt and extensive remedial both to mitigate the effects of the Incident and enhance the robustness of its security measures. This included shutting down the FTA, conducting thorough Page 2 of 3 review of processes and file sharing protocols to enhance information security posture, and offering identity monitoring service to the affected individuals. 7. In view of the above, the Deputy Commissioner for Personal Data Protection is satisfied that the Organisation had met its Protection Obligation under section 24 of the PDPA and cannot be held liable for zero-day vulnerabilities on a third party system. No enforcement action therefore needs to be taken in relation to the Incident. The following provision(s) of the Personal Data Protection Act 2012 had been cited in the above summary: Protection of personal data 24. An organisation shall protect personal data in its possession or under its control by making reasonable security arrangements to prevent – (a) unauthorised access, collection, use, disclosure, copying, modification, disposal or similar risks; and (b) the loss of any storage medium or device on which personal data is stored. Page 3 of 3 ",Not in Breach,572fbbe0157ad79a81e4ed46fce23091a479c4f6,"[""tags"",""decision"",""pdf-url"",""description"",""date"",""timestamp"",""url"",""title"",""nature"",""pdf-content""]" 2023-10-01T11:02:10+08:00,fbd32491db44d3d0c97aa12a99cefd61ec954264,37,37,1,1016,Directions were issued to ACL Construction (S) for breach of the PDPA in relation to failure to appoint a data protection officer and no policies and practices in place to comply with the PDPA.,"[""Accountability"", ""Directions"", ""Construction"", ""No DPO""]",2022-04-21,https://www.pdpc.gov.sg/-/media/Files/PDPC/PDF-Files/Commissions-Decisions/Decision--ACL-Construction-S-Pte-Ltd--030222.pdf,Accountability,Breach of Accountability Obligation by ACL Construction (S),https://www.pdpc.gov.sg/all-commissions-decisions/2022/03/breach-of-accountability-obligation-by-acl-construction,2022-04-21,"PERSONAL DATA PROTECTION COMMISSION Case No. DP-2107-B8598 In the matter of an investigation under section 50(1) of the Personal Data Protection Act 2012 And ACL Construction (S) Pte Ltd SUMMARY OF THE DECISION 1. On 2 June 2021, the Personal Data Protection Commission (the “Commission”) was notified that data from ACL Construction (S) Pte Ltd (the “Organisation”), a company that provides pre-fabricated structures, structural steel products and construction services, was being offered for sale on the darkweb by one “Prometheus” (the “Incident”). 2. Investigations revealed that a few days ago, three ACL staff - a designer and two sales executives had experienced difficulties when they tried to log in to access their files. Thereafter, the ACL staff discovered that the files had been encrypted. The Organisation then sought external IT support. 3. The Organisation informed the Commission that the affected files contained the following data related to their projects: (i) Quotation folder – quotations (to clients and from suppliers), delivery orders, invoices and other supporting documents; (ii) Common folder – project document and photographs; and Page 1 of 3 (iii) Drawing folder – CAD drawings. 4. Our investigations revealed that the affected files contained the names of the Organisation’s customers, the relevant liaison person, their business contact number(s) and/or business email(s). As the names, business contact numbers and business emails were not provided by the individuals concerned for a personal purpose, they would constitute “business contact information” as defined under the Personal Data Protection Act (“PDPA”), and fall outside the scope of the Act by virtue of section 4(5) of the PDPA. Accordingly, while the Organisation may have suffered a data breach, no personal data was in fact affected. 5. This finding alone would have brought the matter to a close. However, in the course of our investigations, the Commission found out that the Organisation had failed to designate one or more individuals, commonly known as a Data Protection Officer (“DPO”), to be responsible for ensuring that the Organisation complies with the PDPA, as required under section 11(3) of the PDPA. The Organisation’s omission to have any data protection policies in place meant that it was also in breach of section 12(a) of the PDPA. 6. The Commission is cognizant that by virtue of the nature of the Organisation’s business, the Organisation primarily deals with business contact information from its corporate clients. Having said that, while no personal data may have been affected as a result of the Incident, the Organisation still has to comply with the accountability obligation, as set out in sections 11 and 12 of the PDPA so as to protect the personal data of its employees, and any other personal data it may incidentally process, come into control or possession of. Page 2 of 3 7. The Commission notes that after the Incident, the Organisation took prompt remedial actions and duly appointed a member of its staff to be responsible for ensuring that the Organisation complies with the PDPA. 8. Nonetheless, bearing in mind the Organisation’s low level of awareness of its obligations under the PDPA, the Commission considered that it would be most appropriate in lieu of imposing a financial penalty, to direct the Organisation to comply with the following: a. To develop and implement policies and practices to comply with the provisions of the PDPA; and b. Put in place a programme of compulsory training for employees of ACL on compliance with the PDPA when handling personal data. The following is the provision of the Personal Data Protection Act 2012 cited in the above summary: Compliance with PDPA 11(3). An organisation must designate one or more individuals to be responsible for ensuring that the organisation complies with the PDPA. Policies and practices 12(a). An Organisation must develop and implement policies and practices that are necessary for the organisation to meet the obligations of the organisation under the PDPA. Page 3 of 3 ",Directions,e5d93d363b4513ab709353939decc81ce04eb8a1,"[""tags"",""decision"",""pdf-url"",""description"",""date"",""timestamp"",""url"",""title"",""nature"",""pdf-content""]" 2023-10-01T11:02:10+08:00,fbd32491db44d3d0c97aa12a99cefd61ec954264,38,38,1,1016,"A financial penalty of $35,000 was imposed on GeniusU for failing to put in place reasonable security arrangements to prevent the unauthorised access and exfiltration of individuals' personal data stored in its staging database.","[""Protection"", ""Financial Penalty"", ""Education""]",2022-04-21,https://www.pdpc.gov.sg/-/media/Files/PDPC/PDF-Files/Commissions-Decisions/Decision---GeniusU-Pte-Ltd--180122.pdf,Protection,Breach of the Protection Obligation by GeniusU,https://www.pdpc.gov.sg/all-commissions-decisions/2022/03/breach-of-the-protection-obligation-by-geniusu,2022-04-21,"PERSONAL DATA PROTECTION COMMISSION Case No. DP-2101-B7725 In the matter of an investigation under section 50(1) of the Personal Data Protection Act 2012 And GeniusU Pte. Ltd. SUMMARY OF THE DECISION 1. On 12 January 2021, GeniusU Pte. Ltd. (the “Organisation”) notified the Personal Data Protection Commission (the “Commission”) of unauthorized access and exfiltration of a staging application database (the “Database”) holding personal data (the “Incident”). 2. The personal data of approximately 1.26 million users were affected. The datasets affected comprised first and last name, email address, location and last sign-in IP address. 3. The Organisation’s internal investigations revealed that the likely cause of the Incident was compromise of one of its developer’s password, either because the developer used a weak password for his GitHub account or the password for his GitHub account had been compromised. This allowed the threat actor to enter 1 the Organisation’s GitHub environment. As the Organisation had stored the login credentials to the Database in the codebase in its GitHub environment, the threat actor was able to gain access to and exfiltrate personal data stored in the Database. 4. The Organisation took the following remedial measures after the Incident: a. Rotated the credentials of the Database; b. Removed all hard-coded credentials from the codebase; c. Purged all existing website sessions; d. Removed all personal data from non-production environment servers, e. Implemented multi-factor authentication on all work-related accounts; f. Implemented a standardised cyber security policy and related procedures for all staff; and g. 5. Notified users and the GDPR data authority (Ireland) of the Incident. The Commission accepted the Organisation’s request for this matter to be handled under the Commission’s expedited breach decision procedure. This meant that the Organisation had voluntarily provided and unequivocally admitted 2 to the facts set out in this decision. The Organisation also admitted that it was in breach of section 24 of the Personal Data Protection Act (the “PDPA”). 6. Based on its admissions, the Organisation had breached the Protection Obligation by: a. Storing credentials for the Database in the codebase in its GitHub environment. This meant that once the threat actor was able to access the GitHub environment, he was able to discover the credentials to access personal data stored in the Database; and b. Storing actual personal data in the Database that was in a nonproduction (testing) environment, which are usually not as secure as production environments. Actual personal data should not be stored in testing environments, which are known to be less secure. 7. In the circumstances, the Organisation is found to be in breach of section 24 of the PDPA. 8. Having considered the circumstances set out above and the factors listed at section 48J(6) of the PDPA and the circumstances of the case, including (i) the Organisation’s upfront voluntary admission of liability which significantly reduced 3 the time and resources required for investigations; and (ii) the prompt remedial actions undertaken by the Organisation, the Organisation is given a notice to pay a financial penalty of $35,000. 9. The Organisation must make payment of the financial penalty within 30 days from the notice accompanying date this decision, failing which interest at the rate specified in the Rules of Court in respect of judgment debts shall accrue and be payable on the outstanding amount of such financial penalty until the financial penalty is paid in full. 10. In view of the remedial actions taken by the Organisation, the Commission will not issue any directions under section 48I of the PDPA. The following is the provision of the Personal Data Protection Act 2012 cited in the above summary: Protection of personal data 24. An organisation shall protect personal data in its possession or under its control by making reasonable security arrangements to prevent – (a) unauthorised access, collection, use, disclosure, copying, modification, disposal or similar risks; and (b) the loss of any storage medium or device on which personal data is stored. 4 ",Financial Penalty,7a86d2d632c8b7dd6e2f8666a6255cf824652a01,"[""tags"",""decision"",""pdf-url"",""description"",""date"",""timestamp"",""url"",""title"",""nature"",""pdf-content""]" 2023-10-01T11:02:10+08:00,fbd32491db44d3d0c97aa12a99cefd61ec954264,39,39,1,1016,"A financial penalty of $20,000 was imposed on Trinity Christian Centre for failing to put in place reasonable security arrangements to prevent the unauthorised access of individuals' personal data hosted in its database servers.","[""Protection"", ""Financial Penalty"", ""Arts, Entertainment and Recreation"", ""Ransomware"", ""Remote Desktop Protocol""]",2022-04-21,https://www.pdpc.gov.sg/-/media/Files/PDPC/PDF-Files/Commissions-Decisions/Decision---Trinity-Christian-Centre-Limited---03022022.pdf,Protection,Breach of the Protection Obligation by Trinity Christian Centre,https://www.pdpc.gov.sg/all-commissions-decisions/2022/03/breach-of-the-protection-obligation-by-trinity-christian-centre,2022-04-21,"PERSONAL DATA PROTECTION COMMISSION Case No. DP-2009-B7057 In the matter of an investigation under section 50(1) of the Personal Data Protection Act 2012 And Trinity Christian Centre Limited SUMMARY OF THE DECISION 1. On 11 March 2021, Trinity Christian Centre Limited (the “Organisation”) notified the Personal Data Protection Commission (the “Commission”) that its database servers containing personal data were infected with ransomware on or around 17 February 2021 (the “Incident”). 2. The Organisation subsequently requested 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 set out in this decision. It also admitted that it was in breach of section 24 of the Personal Data Protection Act (the “PDPA”). 1 The Incident 3. The Organisation runs Trinity Christian Church in Singapore. 4. At the time of the Incident, the database servers contained 72,285 individuals’ data. The types of data affected for each individual varied, and included at times an individual’s name, full identification number, residential address, contact number, email address, photograph, date of birth, age, marital status, education level, and/or description of medical condition (if applicable). 5. Investigations by the Organisation revealed that the Organisation maintained an open and publicly exposed remote desktop protocol port. This allowed a threat actor with access to compromised administrator account credentials to enter the Organisation’s network and database servers to execute ransomware attack on 17 February 2021, rendering the databases inaccessible. 6. The Organisation managed to restore the affected databases from its back-up copies. Based on the Organisation’s investigations, there was no evidence to suggest that the threat actor exfiltrated the Organisation’s databases. The Organisation’s Admission 7. The Organisation admitted that it had breached the Protection Obligation under section 24 of the PDPA as: 2 a. It could have implemented separate access controls (i.e. separate logins) to protect the databases containing personal data; and b. The initial unauthorised entry to the Organisation’s network was through an administrator account that the Organisation had assigned to an IT vendor it had engaged to develop and test applications. The Organisation conceded that it failed to stipulate data protection requirements on its vendor. Remediation 8. Following the Incident, the Organisation notified its church members on 8 April 2021. The Organisation changed all user and administrator passwords, closed all unused and open ports used for remote access and restricted logon access with domain administrator privileges to servers and workstations. A security review was also conducted and the Organisation implemented real time threat monitoring, detection, and response measures. The Commission’s Decision 9. As noted earlier, the Organisation admitted that it was in breach of section 24 of the PDPA as it could have implemented separate access controls to protect the databases containing personal data. In our view, the number and type of personal data sets in the possession or under the control of the Organisation created a 3 security need for stronger access control beyond reliance on frontend password protection. Indeed, with increasingly sophisticated phishing and social engineering techniques, adding another layer of protection to protect backend database servers, and manage the risks that frontend login credentials may be compromised was a reasonable security measure, which the Organisation also accepted. 10. The Commission had also previously emphasised in our decisions1 and in the Commission’s Guide to Managing Data Intermediaries that organisations that engage IT vendors should ensure that their IT vendors are aware of the need for personal data protection by making it part of their contractual terms. 11. The Organisation admitted that its contract with its IT vendor only contained a general confidentiality clause not to disclose information obtained without the Organisation’s prior written consent. Even though the Organisation was well aware that its IT vendor would process personal data, the Organisation failed to stipulate within the contract any requirements on the vendor to protect the church members’ personal data, thereby breaching section 24 of the PDPA. 12. In determining the directions to be imposed on the Organisation for the breach, the Commissioner took into account the following factors: 1 See examples – Jigyasa [2020] SGPDPC 9, MDIS Corporation Pte Ltd [2020] SGPDPC 11 and Civil Service Club [2020] SGPDPC 15. 4 Aggravating (a) The high number of affected individuals of 72,285 which included approximately 8,300 minors; (b) The nature of the affected data. In particular, the affected databases contained descriptions of medical conditions provided by individuals counselling services and overseas mission applications. Individuals would expect a high level of confidence when they convey such information to the Organisation for handling; Mitigating (c) The Organisation’s upfront admission of breach of the Protection Obligation, and the prompt remedial actions to mitigate the effects and prevent recurrence of the Incident; and (d) There was no evidence of exfiltration of the Organisation’s databases. 13. On account of the above, the Organisation is directed to pay a financial penalty of $20,000 within 30 days from the date of this direction. In view of the remedial action of the Organisation, the Commission will not be issuing any other directions. 5 The following provision of the Personal Data Protection Act 2012 had been cited in the above summary: Protection of personal data 24. An organisation shall protect personal data in its possession or under its control by making reasonable security arrangements to prevent – (a) unauthorised access, collection, use, disclosure, copying, modification, disposal or similar risks; and (b) the loss of any storage medium or device on which personal data is stored. 6 ",Financial Penalty,1b58e6ca07c13ad8238e25acd672c8231540a608,"[""tags"",""decision"",""pdf-url"",""description"",""date"",""timestamp"",""url"",""title"",""nature"",""pdf-content""]" 2023-10-01T11:02:10+08:00,fbd32491db44d3d0c97aa12a99cefd61ec954264,40,40,1,1016,"A financial penalty of $21,000 was imposed on Neo Yong Xiang for using his customers' personal data to register for prepaid SIM cards without their consent. The SIM cards were subsequently sold to anonymous individual(s) who used them to send specified messages in contravention of the Do Not Call provisions of the PDPA.","[""Consent"", ""Financial Penalty"", ""Others""]",2022-03-10,https://www.pdpc.gov.sg/-/media/Files/PDPC/PDF-Files/Commissions-Decisions/Decision---Neo-Yong-Xiang---29102021.pdf,Consent,Breach of the Consent and Purpose Limitation Obligations by Neo Yong Xiang trading as Yoshi Mobile,https://www.pdpc.gov.sg/all-commissions-decisions/2022/03/breach-of-the-consent-and-purpose-limitation-obligations-by-neo-yong-xiang-trading-as-yoshi-mobile,2022-03-10,"PERSONAL DATA PROTECTION COMMISSION [2021] SGPDPC 12 Case No. DP-2013-B8088 In the matter of an investigation under section 50(1) of the Personal Data Protection Act 2012 And Neo Yong Xiang (trading as Yoshi Mobile) … Organisation DECISION Neo Yong Xiang (trading as Yoshi Mobile) Lew Chuen Hong, Commissioner — Case No. DP-2013-B8088 29 October 2021 Introduction 1. When customers purchased pre-paid SIM cards from a mobile phone shop at Geylang Road, they would not have anticipated that their personal data would be misused to register additional SIM cards for illegal sale. Unfortunately, this was exactly what happened to at least 78 individuals who purchased pre-paid M1 SIM cards from one Mr Neo Yong Xiang (“NYX”) the sole proprietor of Yoshi Mobile (“YM”). 2. The Commission observed that between January 2020 and November 2020, there were 3,636 Do Not Call (“DNC”) complaints from persons who received specified messages even though their telephone numbers are registered with the DNC register1. Further analysis revealed that 1,379 of the messages were sent from 98 SIM cards registered at YM. The Commission initiated investigations against NYX (trading as YM) for suspected breaches of the Personal Data Protection Act 2012 (“PDPA”). Facts of the Case 3. NYX has operated YM since 2013. As an exclusive retailer of M1 SIM cards, NYX was provided a terminal device installed at YM’s premises for the purposes of 1 Under Section 43 of the PDPA, a person is not allowed to send specified messages to a Singapore telephone number registered with the DNC register unless the person has, at the time where he sends the specified message, valid confirmation that the Singapore telephone number is not listed in the DNC register. SIM card registration (the “M1 Terminal Device”). SIM card registration had to be carried out in accordance with the conditions of M1’s telecommunications licence granted under Section 5 of the Telecommunications Act (Chapter 323). The typical SIM card registration process in YM would be as follows: (a) First, the customer’s identity document (e.g. identity card, passport, work pass etc.) would be scanned using the M1 Terminal Device. The system would capture the customer’s personal data, and state whether the customer had reached the permitted limit of 3 prepaid SIM cards. (b) Next, the barcode of the SIM card(s) would be scanned so that they could be tagged to the registered customer. (c) Finally, a mobile application would be used to load credit value to the prepaid SIM card(s) to activate them for usage. M1’s policy was for each prepaid M1 SIM card to have a zero-initial balance, and for retailers to load some or all of the money paid by the customer. 4. The Commission’s investigations revealed that NYX exploited the above registration process in order to use his customers’ personal data without consent to register for additional prepaid M1 SIM cards that his customers did not intend to purchase. NYX would do so by one of two methods: (a) Method 1 – After scanning a customer’s identity documents via the M1 Terminal Device, NYX would check whether the customer was still entitled to purchase more SIM cards (in addition to the SIM card(s) that were intended to be purchased). If so, NYX would proceed to register additional SIM card(s) to the same customer without their knowledge (the “illicit SIM card(s)”). (b) Method 2 – Occasionally, customers who had completed the registration process would not want to continue with their purchase after learning that the credit value of the SIM card would have to be separately loaded. At this juncture, instead of cancelling or reversing the registration process, NYX would keep the SIM card(s) and activate them without the customer’s knowledge. 5. During investigations, NYX admitted that his purpose for registering the illicit SIM cards was to sell them to earn extra money. In his three years of selling such illicit SIM cards to anonymous walk-in customers, NYX estimated that he earned approximately $15,000 (i.e. around 100 illicit SIM cards per year at a price of $50 per card). 6. The affected personal data collected and used by NYX to register the illicit SIM cards include, at a minimum, the following personal data of 78 individuals (used to register 94 SIM cards): (a) the customers’ names; (b) the customers’ addresses; and (c) the customers’ NRIC numbers and/or work permit numbers. 7. After registering the illicit SIM cards, NYX would sell them to anonymous buyers who occasionally patronised YM from 2018 to 2020. Investigations revealed that illicit SIM cards registered at YM were exploited by unknown perpetrators to send unsolicited spam and/or scam messages, often also in contravention of the DNC provisions of the PDPA. Findings and Basis for Determination 8. Section 2(1) of the PDPA defines an “organisation” broadly to include “any individual, company, association or body of persons, corporate or unincorporated”. YM is a sole proprietorship and has no separate legal personality from NYX. Accordingly, NYX constitutes an organisation under the PDPA Further, NYX is bound by the provisions of the PDPA (including Part IV) as he was acting in a business capacity in selling the SIM cards to make a profit, and not a domestic capacity. As stated in Re Sharon Assya Qadriyah Tang [2018] SGPDPC 1: “9 …Although the PDPA defines “organisation” broadly to include individuals, an individual is expressly excluded from the Data Protection Provisions in the PDPA if the individual was acting in a personal or domestic capacity. Therefore, when it comes to the application of the PDPA to individuals, it is usually germane to the issue to determine whether the individual was acting in a personal or domestic capacity. If the individual was not acting in a personal or domestic capacity, then she will be treated as an “organisation” for the purposes of the PDPA, and obliged to comply with the Data Protection Provisions. 10 On the facts, the Respondent was clearly not acting in a personal or domestic capacity in respect of the buying and selling of leads. The purchase and sales of the leads were not for her own personal use or purposes, but in order to make a profit. Under the PDPA, “business” includes an activity of any organisation, whether or not carried on for purposes of gain, or conducted on a regular, repetitive or continuous basis, but does not include an individual acting in his personal or domestic capacity. In this regard, the converse of a person acting in a personal or domestic capacity is one that acts in a business capacity. This was the case for the Respondent in respect of the purchase and sale of leads.” [emphasis added] 9. Based on the circumstances set out above, the issues to be determined in this case are: (a) Whether NYX breached the Consent Obligation under section 13 of the PDPA; and (b) Whether NYX breached the Purpose Limitation Obligation under section 18 of the PDPA. The Consent Obligation under section 13 of the PDPA 10. Under Section 13 of the PDPA, organisations are prohibited from collecting, using or disclosing an individual’s personal data unless the individual gives, or is deemed to have given, his consent, an exception to the requirement for consent applies, or if otherwise authorised under the PDPA or any other written law (the “Consent Obligation”). In this connection, Section 14(1) of the PDPA further provides that an individual has not given consent unless he has been notified of the purposes for which his personal data was being collected, used or disclosed. If an organisation fails to do so, any consent obtained from an individual is invalid. 11. On the facts of this case, NYX breached the Consent Obligation by using his customers’ personal data to register the illicit SIM cards for sale to anonymous buyers. When NYX used Method 1, NYX’s customer(s) only consented to the collection and use of their personal data for the purpose of registering the number of SIM cards which they had requested. They did not provide consent to NYX to use their personal data for any other purpose, including the registration of additional SIM cards. 12. In the case of Method 2, the customers withdrew their consent to the collection and use of their personal data to purchase M1 SIM cards, and NYX should have cancelled the SIM card registrations. Instead, he went behind his customers’ backs and used their personal data without consent to register illicit SIM cards. 13. In the premises, NYX is determined to have breached the Consent Obligation by using his customers’ personal data without their consent. The Purpose Limitation Obligation under Section 18 of the PDPA 14. Under Section 18 of the PDPA, an organisation may collect, use or disclose personal data about an individual only for purposes that a reasonable person would consider appropriate in the circumstances, and where that individual has been informed of the said purposes under Section 20 of the PDPA (the “Purpose Limitation Obligation”). As set out in the Commission’s Advisory Guidelines on Key Concepts in the PDPA2: “The main objective of the Purpose Limitation Obligation is to ensure that organisations collect, use and disclose personal data that are relevant for the purposes, and only for purposes that are reasonable. Consistent with the Notification Obligation, the Purpose Limitation Obligation also limits the purposes for which personal data may be collected, used or disclosed to those 2 Advisory Guidelines on Key Concepts in the PDPA (Rev 1 February 2021) which have been informed to the individuals concerned pursuant to the Notification Obligation (where applicable). For the purposes of section 18 (and as stated in that section), whether a purpose is reasonable depends on whether a reasonable person would consider it appropriate in the circumstances. Hence the particular circumstances involved need to be taken into account in determining whether the purpose of such collection, use or disclosure is reasonable. For example, a purpose that is in violation of a law or which would be harmful to the individual concerned is unlikely to be considered appropriate by a reasonable person.” [emphasis added] 15. The Purpose Limitation Obligation operates independently from the Consent Obligation. Even if the data subject gave his consent for his personal data to be used for a particular purpose, it does not follow that the said purpose is reasonable in the circumstances. As stated in Re AIA Singapore Pte Ltd [2016] SGPDPC 10 at [18]: “Section 18 of the PDPA provides, inter alia, that an organisation may collect, use or disclose personal data about an individual only for purposes that a reasonable person would consider appropriate in the circumstances. It should be borne in mind that Section 18 of the PDPA is an independent obligation that organisations would need to comply with even if it had obtained the consent from the relevant individual for the collection, use or disclosure of his or her personal data. This is an important aspect of the PDPA as it is effective in addressing excesses in the collection, use or disclosure of personal data under a broadly-worded consent clause, like in the present case.” [emphasis added] 16. In this case, NYX has admitted that he had fraudulently used his customers’ personal data for the purpose of registering illicit SIM cards in order to sell them to anonymous buyers. This is plainly not a reasonable purpose under any circumstances, as individuals could not have reasonably intended for their personal data to be used to register illicit SIM cards purely for NYX’s financial gain. 17. In the premises, NYX is determined to have breached the Purpose Limitation Obligation. The Commissioner’s Decision 18. In determining whether NYX should be required to pay a financial penalty under section 48J of the PDPA, the factors listed at section 48J(6) of the PDPA were considered, with particular emphasis on the following aggravating and mitigating factors: Aggravating Factors (a) NYX’s breaches of the PDPA were difficult to detect as it included a high degree of planning and pre-meditation by him to evade detection by authorities; (b) NYX was entrusted by his customers with their personal data for the purpose of registering prepaid SIM cards, and he abused their trust by misusing their personal data; (c) NYX’s breaches of the PDPA caused inconvenience to innocent parties, as the illicit SIM cards sold by him were used to send unsolicited messages to phone numbers that were registered with the DNC register; (d) Through the sale of the illicit SIM cards for approximately 3 years, NYX financially gained at least $15,000 for his misuse of his customers’ personal data; and Mitigating Factor (e) NYX admitted to liability early in the investigation process, thus reducing the time and resources expended on investigations. NYX’s representations 19. On 7 September 2021, NYX was notified of the Commissioner’s Preliminary Decision (as set out above) and intention to impose a financial penalty of $35,000. On 20 September 2021, NYX submitted written representations on the amount of financial penalty that was to be imposed. NYX raised the following factors to argue for either a waiver of the imposition of a financial penalty, or (in the alternative) for a lower financial penalty: (a) NYX was facing a difficult financial situation, as he had low savings / monthly income, and was responsible for servicing several outstanding liabilities (such as a vehicle loan, housing loan and renovation loan). Additionally, he was also responsible for paying the medical bills of his parent. NYX claimed that it would cause him undue hardship if a high financial penalty was imposed. (b) NYX had breached the PDPA for financial gain due to extenuating circumstances, as his business was adversely affected by COVID-19 and the landlord of Yoshi Mobile had refused to pass on the relevant COVID-19 rental relief provided by the Government. (c) NYX’s breaches of the PDPA can be distinguished from the breaches committed by other organisations on the basis that he did not leak or sell the personal data for financial gain. Instead, he had merely used his customers’ personal data to register for SIM cards and was not the person who used the illicit SIM cards to send unsolicited text messages to telephone numbers on the DNC register. In this connection, NYX pointed to other decisions where the Commission had imposed a lower financial penalty or a warning on other organisations that had breached the PDPA. 20. After careful consideration, we have accepted and taken into account NYX’s representation at [19(a)] above, but are unable to do the same with respect to the representations set out in [19(b)] and [19(c)] above. 21. When imposing financial penalties, the Commission may consider the personal and financial circumstances of the organisation / individual, bearing in mind that financial penalties imposed should avoid imposing a crushing burden or cause undue hardship on organisations: see Re Jigyasa [2021] SGPDPCR 1. In considering NYX’s representations at [19(a)], the Commission gave due consideration to the existing financial commitments on NYX and accepted that the imposition of a heavy financial penalty would cause substantial hardship to NYX. 22. We are unable to accept NYX’s representation at [19(b)] that he had breached the PDPA due to extenuating financial difficulties that arose due to the COVID-19 pandemic. Based on the Commission’s investigations, NYX has been using his customers’ personal data to register illicit SIM cards for the purpose of selling them to third parties since 2018. NYX’s modus operandi (as described in [4]) predated the onset of COVID-19, and it is disingenuous for NYX to attribute his actions to the financial difficulties that followed the COVID-19 pandemic. 23. We are also unable to accept NYX’s representation at [19(c)] that his breach of the PDPA was less serious than the breaches committed by various other organisations. Compared with the decisions that NYX mentioned, NYX’s culpability is more egregious as his breach involved the intentional misuse of personal data from a position of trust, over a protracted period of time, for personal financial gain. While NYX did not send any unsolicited text messages or made any unsolicited calls directly to telephone numbers on the DNC register, his sale of the unsolicited SIM cards to anonymous buyers (that NYX did not verify or identify) facilitated the commission of those offences and the harm caused as a consequence. The anonymous sale of illicit SIM cards may also be the catalyst or precursor for other illicit activities. 24. Having carefully considered the all the relevant factors of this case including the representations made by NYX, the Commissioner has decided to reduce the financial penalty to $21,000. This decision is made on an exceptional basis, and should not be taken as setting any precedent for future cases. The Commissioner hereby requires NYX to pay a financial penalty of $21,000 in 18 monthly instalments by the due dates as set out in the notice accompanying this decision, failing which interest at the rate specified in the Rules of Court in respect of judgment debts shall accrue and be payable on the outstanding amount of such financial penalty until the financial penalty is paid in full. 25. The Commission will not be issuing any further directions given that M1 has barred NYX from offering the sale of its prepaid SIM cards. YEONG ZEE KIN DEPUTY COMMISSIONER FOR COMMISSIONER FOR PERSONAL DATA PROTECTION ",Financial Penalty,9701ccc45e49e35f3e4018e10b92d445aca1c569,"[""tags"",""decision"",""pdf-url"",""description"",""date"",""timestamp"",""url"",""title"",""nature"",""pdf-content""]" 2023-10-01T11:02:10+08:00,fbd32491db44d3d0c97aa12a99cefd61ec954264,41,41,1,1016,"A financial penalty of $4,000 was imposed on Tanah Merah Country Club for failing to put in place reasonable security to protect personal data in its possession. The incident resulted in personal data being accessed.","[""Protection"", ""Financial Penalty"", ""Arts, Entertainment and Recreation"", ""Email"", ""Password policy""]",2022-02-18,https://www.pdpc.gov.sg/-/media/Files/PDPC/PDF-Files/Commissions-Decisions/Decision---Tanah-Merah-Country-Club---20122021.pdf,Protection,Breach of the Protection Obligation by Tanah Merah Country Club,https://www.pdpc.gov.sg/all-commissions-decisions/2022/02/breach-of-the-protection-by-tanah-merah-country-club,2022-02-18,"PERSONAL DATA PROTECTION COMMISSION Case No. DP-2102-B7951 In the matter of an investigation under section 50(1) of the Personal Data Protection Act 2012 And Tanah Merah Country Club SUMMARY OF THE DECISION 1. On 24 February 2021, Tanah Merah Country Club (the “Organisation”) notified the Personal Data Protection Commission (the “Commission”) that an employee’s (the “Employee”) email account had been compromised and 600 phishing emails had been sent to various individuals on 22 February 2021 (the “Incident”). 2. The Organisation subsequently requested for this matter to be handled under the Commission’s expedited breach decision procedure. This meant that the Organisation voluntarily and unequivocally admitted to the facts set out within this decision. It also admitted that it was in breach of section 24 of the Personal Data Protection Act (the “PDPA”). 3. The Organisation’s investigations revealed that it was likely that the Organisation’s email accounts had been subjected to password spraying attacks. Password spraying is a type of password attack where a threat actor uses a few commonly used or default passwords against many different accounts. In contrast to traditional brute-force attacks, where the targeted account may quickly get lockedout due to account-lockout policies that only allow for a limited number of failed attempts, password spraying attacks allow a threat actor to mount an attack against many accounts with a single commonly used password, while remaining undetected, before attempting the second password. At the time of the Incident, the Employee was using the password “TMCC@1234”, which the Employee had not changed for a period of nearly 5 years, since 2016 to the time of the Incident on 22 February 2021. 4. After gaining access to the Employee’s email account, the threat actor accessed the personal data of 467 individuals, including: a. The email addresses of 155 club members and 284 members of public, which the threat actor had used to send phishing emails to. b. The name, and/or NRIC number, and/or email addresses of a further 28 individuals contained within the emails. 5. Prior to the Incident, the Organisation had informed its employees via an email IT newsletter in August 2018 of the need to change their password once every 3 months, and to use passwords which are at least 8 characters, with a combination of uppercase letter, lowercase letter, special character, and number. In September 2019, the Organisation sent another email IT newsletter to inform its employees of the implementation of a domain password policy. This meant that the abovementioned password requirements became system enforced. 6. Despite disseminating these email IT newsletters where it referred to its password requirements and the implementation of a system-enforced domain password policy, the Organisation failed to further develop its password requirements into a full-fledged password policy in writing and disseminate it in such a manner whereby all its employees, new and old, could easily take reference from the password policy and consult the password policy at any time. It was only on 23 February 2021, after the Incident had occurred, that the Organisation documented its password policy in writing. 7. We had previously emphasized the importance of organisations having a written personal data protection policy so as to guide its employees and staff in Re Furnituremart.sg [2017] SGPDPC 7. In that case, the Commission noted at [14] as follows: “The lack of a written policy is a big drawback to the protection of personal data. Without having a policy in writing, employees and staff would not have a reference for the organisation’s policies and practices which they are to follow in order to protect personal data. Such policies and practices would be ineffective if passed on by word of mouth, and indeed, the Organisation may run the risk of the policies and practices being passed on incorrectly. Having a written policy is conducive to the conduct of internal training, which is a necessary component of an internal data protection programme”. 8. A properly documented password policy is therefore crucial for the protection of personal data. In this regard, the Organisation admitted that it had breached the Protection Obligation under section 24 of the PDPA as it failed to document its password policy in writing. 9. The Commission recently issued a “Guide to Data Protection Practices for ICT Systems” on 14 September 2021. In the Guide, we noted that in order to maintain good governance over its personal data and mitigate data breach risks throughout the data lifecycle, organisations should develop and implement ICT security policies for data protection. Key ICT policies would include a password policy. 10. Prior to the issuance of this Guide, the Commission had also released a Handbook on “How to Guard Against Common Types of Data Breaches”, which is complemented by the Checklists to Guard Against Common Types of Data Breaches. In the Handbook, the Commission identified poor management of accounts and passwords as one of the five common causes and types of data breaches. We noted that the use of default value, weak or easily guessable passwords result in accounts being particularly vulnerable to brute force or dictionary attacks. We therefore recommended that organisations adopt and implement a strong password policy, with the following good practices: (i) Enforcing a password history policy to ensure that employees do not reuse their previous passwords; (ii) Encouraging users to use passphrases such as “Iwant2l@se10kg”, which may be long and complex, yet easy to remember; and (iii) Discouraging users from using the same passwords across different systems. 11. In this regard, we observed that the Organisation’s email IT newsletters to its employees had cited “TMCC_Password_123” as an example of what amounts to a good password. Unfortunately, we are unable to endorse the Organisation’s choice of “TMCC_Password_123” as an example of what amounts to a good password. In Re Chizzle Pte Ltd [2020] SGPDPCR 1, the Commission highlighted that a password that complies with the recommended password complexity rules in form could still be a weak password easily guessable and vulnerable to password attacks if the password incorporates components such as the organisation’s name, which is not difficult to guess and crack. In this regard, we note that in the Organisation’s password policy, which it adopted on 23 February 2021, the Organisation now recommends that its employees refrain from the use of the Organisation’s name or abbreviations such as “TMCC”. 12. In addition, the Organisation also admitted that it had failed to provide structured and organised training for its staff on how to ensure compliance with the obligations under the PDPA and how personal data should be handled in the course of their work. Only ad-hoc and informal training had been provided. As a result, the Employee lacked the awareness of the need to change her password at more regular intervals and of the need to use a strong password. The Employee did not receive system prompts to change her password as the domain password policy was not pushed down to her system due to a domain controller disruption. 13. The Commission wishes to emphasize that staff training is a critical and necessary component to ensure that an organisation is well placed to protect the personal data in its possession and/or control. The Protection Obligation under section 24 of the PDPA extends to and includes the training of all employees who have to handle personal data in the course of their work so that an organisation’s employees can then successfully adopt and implement the policies and best practices necessary to ensure the protection of personal data in an organisation’s possession and/or control. 14. In light of the above, 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 (the “PDPA”). 15. Following the incident, the Organisation engaged an IT forensic vendor for investigation. We note that the Organisation has since implemented the measures recommended by the vendor to improve its cybersecurity. The Organisation has also documented its password policy, implemented regular updates, conducted user awareness training, and other trainings on personal data protection. 16. The Organisation cooperated with the Commission’s investigations, admitted to its breach of the Protection Obligation, and took prompt remedial actions. 17. Having considered the circumstances set out above, the factors listed at section 48J(6) of the PDPA, and in particular, the Organisation’s voluntary admission to being in breach of section 24 of the PDPA under the Expedited Breach Decision Procedure, which is a significant mitigation factor, the Deputy Commissioner for Personal Data Protection requires the Organisation to pay a financial penalty of $4,000 within 30 days from the notice accompanying date this decision, failing which interest at the rate specified in the Rules of Court in respect of judgment debts shall accrue and be payable on the outstanding amount of such financial penalty until the financial penalty is paid in full. 18. Finally, in view of the remedial actions taken by the Organisation, no other directions are necessary. The following is the provision of the Personal Data Protection Act 2012 cited in the above summary: Protection of personal data 24. An organisation shall protect personal data in its possession or under its control by making reasonable security arrangements to prevent – (a) unauthorised access, collection, use, disclosure, copying, modification, disposal or similar risks; and (b) the loss of any storage medium or device on which personal data is stored. ",Financial Penalty,db3f5f6adf8ce0a020293ba554d69dc62a612298,"[""tags"",""decision"",""pdf-url"",""description"",""date"",""timestamp"",""url"",""title"",""nature"",""pdf-content""]" 2023-10-01T11:02:10+08:00,fbd32491db44d3d0c97aa12a99cefd61ec954264,42,42,1,1016,"A financial penalty of $10,000 was imposed on North London Collegiate School (Singapore) for failing to put in place reasonable security arrangements to prevent the unauthorised access of its student applicants’ personal data residing in a website directory folder.","[""Protection"", ""Financial Penalty"", ""Education""]",2022-02-18,https://www.pdpc.gov.sg/-/media/Files/PDPC/PDF-Files/Commissions-Decisions/Decision---NLCS---01122021.pdf,Protection,Breach of the Protection Obligation by North London Collegiate School (Singapore),https://www.pdpc.gov.sg/all-commissions-decisions/2022/02/breach-of-the-protection-obligation-by-north-london-collegiate-school,2022-02-18,"PERSONAL DATA PROTECTION COMMISSION Case No. DP-2107-B8562 In the matter of an investigation under section 50(1) of the Personal Data Protection Act 2012 And North London Collegiate School (Singapore) Pte. Ltd. SUMMARY OF THE DECISION 1. On 2 July 2021, North London Collegiate School (Singapore) Pte. Ltd. (the “Organisation”) notified the Personal Data Protection Commission (the “Commission”) that a parent of a student was able to view and access a student report by the Organisation by performing searches using internet search engines. (the “Incident”). 2. The Organisation subsequently requested 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 set out in this decision. It also admitted that it was in breach of section 24 of the Personal Data Protection Act (the “PDPA”). 3. Investigations revealed that, from December 2019 to July 2021, parents of prospective students could submit documents for admission applications via the Organisation’s website (https://nlcssingapore.sg/). All submitted documents were stored in a directory/ folder of the website. However, the website directory/ 1 folder was not adequately secured from automatic indexing by web crawlers. As a result, the submitted documents were indexed by search engines and could show up in online search results. 4. The table below summarises1 the number of affected individuals for each type of document accessible in the directory/ folder (the “Compromised Documents”): S/N 5. Type of Document Number (Scanned or Electronic Copies) Affected 1 Passport 1,742 2 Identity cards (i.e NRICs) 1,714 3 Digital Photographs of applicants 720 4 Birth Certificates 709 5 Academic Reports 676 6 Immunization Records 670 of Individuals The documents above contained the following types of personal data (the “Personal Data Sets”) at risk of unauthorised access in the Incident - Name, Address, NRIC number, Passport Number, Photograph, Date of Birth, immunization details and academic details. 6. The Organisation admitted that it had only relied on a Robots.txt file deployed on its Website to instruct search engines to refrain from indexing the documents in the website directory folder. However, it is well established that the robots exclusion protocol is not mandatory, in the sense that it relies on compliance of 1 This table sets out the documents at risk of unauthorised access in the Incident. Not all of these types of documents were affected for each Affected Individual, and the documents affected for each Affected Individual varies. A unique Affected Individual could have multiple type of documents affected. 2 web crawlers without an enforcement mechanism. Therefore, Organisations storing personal data in website directory/ folders should instead implement proper folder or directory permissions and access controls to prevent unintended access by web crawlers. 7. In addition, the Organisation had stated that it relied on a related group company to setup and manage its website, including to make the necessary security arrangements to protect any personal data collected. However, in this case, there were no clear business requirements (e.g. contractual stipulations) specifying that the Organisation was relying on the sister company to recommend and/or implement security arrangements to protect personal data that resides in the website directory/ folder. 8. Re Everlast Projects Pte Ltd & Others [2020] SGPDPC 20 stated the arrangements to be made when organisations in a group used IT services provided by a group member. An organisation receiving IT services from another organisation of the group should ensure that the latter is bound by either written agreements or group rules to protect personal data in the course of provision of the services. Absent clear written personal data protection requirements of the group member managing the Organisation’s website, the responsibility to make reasonable security arrangements to protect the Affected Personal Data in the directory/ folder of the website remained squarely with the Organisation. 3 9. In the circumstances, 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 (the “PDPA”). 10. Following the incident, the Organisation ceased the collection of documents via its website and would now be utilizing a specialized school admission software to manage the application process and the personal data submitted. Additionally, the Organisation would be implementing appropriate binding corporate rules to govern the centralization of corporate functions and the handling of data protection and cybersecurity within its corporate group. 11. The Organisation cooperated with the Commission’s investigations, admitted to its breach of the Protection Obligation and took prompt remedial actions to address its inadequacies in its processes. There were also no indications that that the personal data affected in the Incident had been misused in any form. However, personal data of minors were at risk of unauthorised access. 12. Having considered the circumstances set out above and the factors listed at section 48J(6) of the PDPA, the Deputy Commissioner for Personal Data Protection requires the Organisation to pay a financial penalty of $10,000 within 30 days from the notice accompanying date this decision, failing which interest at the rate specified in the Rules of Court in respect of judgment debts shall accrue and be payable on the outstanding amount of such financial penalty until the financial penalty is paid in full. 4 13. In view of the remedial actions taken by the Organisation, no other directions are necessary. The following is the provision of the Personal Data Protection Act 2012 cited in the above summary: Protection of personal data 24. An organisation shall protect personal data in its possession or under its control by making reasonable security arrangements to prevent – (a) unauthorised access, collection, use, disclosure, copying, modification, disposal or similar risks; and (b) the loss of any storage medium or device on which personal data is stored. 5 ",Financial Penalty,2b442c9cd53b17e7887a8bb1bdfc113eeb21ae47,"[""tags"",""decision"",""pdf-url"",""description"",""date"",""timestamp"",""url"",""title"",""nature"",""pdf-content""]" 2023-10-01T11:02:10+08:00,fbd32491db44d3d0c97aa12a99cefd61ec954264,43,43,1,1016,"A financial penalty of $14,000 was imposed on Nature Society (Singapore) for breaches of the PDPA. First, the organisation failed to put in place reasonable measures to protect personal data on its website database. Second, it did not appoint a data protection officer. Lastly, it did not have written policies and practices necessary to comply with the PDPA.","[""Protection"", ""Accountability"", ""Financial Penalty"", ""Others""]",2022-01-14,https://www.pdpc.gov.sg/-/media/Files/PDPC/PDF-Files/Commissions-Decisions/Summary-Decision---NSS---03122021.pdf,"Protection, Accountability",Breach of the Protection and Accountability Obligations by Nature Society (Singapore),https://www.pdpc.gov.sg/all-commissions-decisions/2021/12/breach-of-the-protection-and-accountability-obligations-by-nature-society,2022-01-14,"PERSONAL DATA PROTECTION COMMISSION Case No. DP-2011-B7351 In the matter of an investigation under section 50(1) of the Personal Data Protection Act 2012 And Nature Society (Singapore) SUMMARY OF THE DECISION 1. On 6 November 2020, the Personal Data Protection Commission (the “Commission”) received information of an online article reporting about hacked databases being made available for downloads on several hacking forums and Telegram channels. In the article, Nature Society (Singapore) (the ""Organisation"") was named as one of the affected Organisations (the “Incident”). 2. The personal data of 5,131 members and non-members who had created membership and user accounts on the Organisation’s website were affected in the Incident. The datasets affected comprised of names, usernames, passwords (encrypted), email addresses, telephone numbers, types of membership, gender, mailing addresses, dates of births, occupation, company and nationality. 1 3. Following the Incident, the Organisation engaged two IT professionals to carry out an investigation and analysis of the Organisation's website. The investigation and analysis revealed vulnerabilities in the Organisation's website and suspicious SQL injection activities prior to the Incident. The possible attack vector was identified as a SQL injection attack which led to personal data on the Organisation's website database being accessed and exfiltrated by unknown parties. 4. The Organisation took the following remedial measures after the Incident: (a) Edited the website to stop all online membership sign-ups/renewals and logins to the website; (b) Removed all members' and users' data from the website database; (c) Backed up the website database and kept all personal data offline; (d) Change all login passwords; (e) Notified all affected individuals of the Incident via email; (f) Appointed a Data Protection Officer (""DPO"") (g) Developed and implemented a personal data policy; and (d) Engaging vendors to develop a new website to improve security. 5. In its representations to the Commission, the Organisation admitted to having breached the Accountability Obligation under sections 11(3) and 12(a) and the Protection Obligation under section 24 of the Personal Data Protection Act 2012 (""PDPA""), and requested for the matter to be dealt with in accordance with the Commission’s Expedited Decision Procedure. 2 Breach of Section 11(3) of the PDPA 6. First, the Organisation admitted it did not designate one or more individuals (typically referred to as a DPO) to be responsible for ensuring that the Organisation complies with the PDPA. The responsibilities of a DPO includes (a) ensuring compliance with the PDPA, (b) fostering a data protection culture, (c) handling and managing personal data queries and complaints, (d) alerting management to any risks with regard to personal data and (e) liaising with the Commission if necessary. From the foregoing, it is clear that the DPO plays a vital role in implementing and building a robust data protection framework to ensure an organisation’s compliance with its obligations under the PDPA. Breach of Section 12(a) of the PDPA 7. Second, the Organisation admitted it did not develop and implement any personal data protection policy prior to the Incident. In this regard, it is important to reiterate that at the very basic level, an overarching personal data protection policy has to be developed and implemented to ensure a consistent minimum data protection standard across an organisation's practices, procedures and activities. Breach of Section 24 of the PDPA 3 8. Third, the Organisation admitted that it did not make reasonable security arrangements to protect the personal data on its website database. After the Organisation's website was designed and developed by an external vendor in 2011, the Organisation did not have any contract/retainer agreement with the external vendor to maintain the website's security. As a result, the responsibility of protecting its website fell squarely on the Organisation. However, the Organisation failed to carry out any security measures e.g. conducting necessary security updates, patches and penetration tests, thus leaving its website vulnerable to attacks. 9. In the circumstances, the Organisation is found to have breached sections 11(3), 12(a) and 24 of the PDPA. Commission’s Decision 10. After considering the factors listed at section 48J(6) of the PDPA and the circumstances of this case, including (i) the Organisation's upfront voluntary admission of liability which significantly reduced the time and resources required for investigations; (ii) the fact that the Organisation is a non-profit, registered society and (iii) the Organisation's prompt remedial actions, the Organisation is given notice to pay a financial penalty of $14,000. 4 11. The Organisation must make payment of the financial penalty within 30 days from the date of the notice accompanying this decision, failing which interest at the rate specified in the Rules of Court in respect of judgment debts shall accrue and be payable on the outstanding amount of such financial penalty until the financial penalty is paid in full. 12. In view of the remedial actions taken by the Organisation, the Commission will not issue any directions under section 48I of the PDPA. The following are the provision of the Personal Data Protection Act 2012 cited in the above summary: Compliance with Act 11(3). An organisation shall designate one or more individuals to be responsible for ensuring that the organisation complies with this Act. Policies and practices 12(a). An organisation shall develop and implement practices that are necessary for the organisation to meet the obligations of the organisation under this Act. Protection of personal data 24. An organisation must protect personal data in its possession or under its control by making reasonable security arrangements to prevent – (a) unauthorised access, collection, use, disclosure, copying, modification or disposal or similar risks and; (b) the loss of any storage medium or device on which personal data is stored. 5 ",Financial Penalty,50aef1ea4a6b3252366a112e13092602d7c8bd3b,"[""tags"",""decision"",""pdf-url"",""description"",""date"",""timestamp"",""url"",""title"",""nature"",""pdf-content""]" 2023-10-01T11:02:10+08:00,fbd32491db44d3d0c97aa12a99cefd61ec954264,44,44,1,1016,A warning was issued to Belden Singapore for a breach of the PDPA in relation to the transfer of its Singapore-based employees’ personal data to its parent company in the United States.,"[""Transfer Limitation"", ""Warning"", ""Manufacturing""]",2021-12-09,https://www.pdpc.gov.sg/-/media/Files/PDPC/PDF-Files/Commissions-Decisions/Decision---Belden-Singapore-Private-Limited---12112021.pdf,Transfer Limitation,Breach of the Transfer Limitation Obligation by Belden Singapore,https://www.pdpc.gov.sg/all-commissions-decisions/2021/12/breach-of-the-transfer-limitation-obligation-by-belden-singapore,2021-12-09,"PERSONAL DATA PROTECTION COMMISSION [2021] SGPDPC 13 Case No. DP-2011-B7423, DP-2011-B7433 In the matter of an investigation under section 50(1) of the Personal Data Protection Act 2012 And (1) Belden Singapore Private Limited (2) Grass Valley Singapore Pte Ltd … Organisations DECISION 1 Belden Singapore Private Limited & Anor [2021] SGPDPC 13 Yeong Zee Kin, Deputy Commissioner — Case No. DP-2011-B7423, DP-2011B7433 12 November 2021 Introduction 1. It is not unusual for a corporate group with a multi-national footprint to conduct cross-border transfers of personal data between its various entities. However, such arrangements also mean that data transferred from an organisation based in Singapore might risk exposure to data breach incidents in another jurisdiction. This is one such incident. 2. On 19 November 2020 and 20 November 2020, Belden Singapore Private Limited (“Belden Singapore”) and Grass Valley Singapore Pte Ltd (“GVSPL”) (collectively, the “Organisations”) notified the Personal Data Protection Commission (the “Commission”) of a data breach incident whereby an unauthorised third party had gained access to business servers of the Belden Group, and managed to exfiltrate information, including personal data of the employees of the Organisations (“Incident”). 2 Facts of the Case 3. The Belden Group is a group of companies involved in the manufacturing of networking, connectivity and cable products. Its various subsidiaries and affiliated companies operate in the Americas, Europe, Middle East, Africa and the Asia Pacific region (the “Belden entities”). The overall parent entity, Belden Incorporated (“Belden Inc.”) is headquartered in St Louis, Missouri, United States. Belden Singapore is part of the Belden Group. 4. As the main Human Resources (“HR”) functions of Belden Singapore are conducted by Belden Inc., Belden Singapore transfers the personal data of its employees to Belden Inc., which are then stored in Belden Inc.’s servers. The terms on which the various Belden entities transfer and process personal data are governed by the Global Data Transfer Agreement dated 1 September 2020 (“GDTA”). 5. GVSPL is part of a group of companies (the “Grass Valley entities”) that were formerly part of the global Belden Group. In July 2020, the Grass Valley entities (including GVSPL) were acquired by another company. Under the terms of the acquisition, Belden Inc. agreed to provide transition services, including administration of its information technology and HR systems for a period of time after the acquisition. Therefore, the personal data of GVSPL’s employees (and the employees of other Grass Valley entities) were transferred to Belden Inc. and stored in Belden Inc.’s servers. GVSPL’s parent company, Grass Valley USA, LLC (“GV USA”) (on behalf of its subsidiaries and affiliates, including GVSPL) and Belden Inc. entered into a Data 3 Sharing Agreement dated 18 June 2020 (“DSA”) to govern the sharing of data (including personal data) between the parties. 6. On 12 November 2020, the Belden Group’s information technology team noticed anomalies in its systems. Subsequent investigations revealed that, from September to November 2020, a threat actor had accessed the Belden Group’s servers in the USA and other jurisdictions through the use of malicious software at various times and exfiltrated the information and data contained therein. The compromise of GVSPL’s Personal Data Sets is taken to have arisen from the unauthorised access to the Belden Group’s servers since there was no evidence of any unauthorised access directly into the systems of the Grass Valley entities. 7. The personal data of 126 individuals related to Belden Singapore (current and former employees as well as non-employees such as suppliers / vendors) and 63 individuals related to GVSPL (current and former employees) were exfiltrated in the Incident (collectively, the “Personal Data Sets”). The types of personal data exfiltrated included the following: (a) Name; (b) Address; (c) Email Address; (d) Telephone Number; (e) Date of Birth; (f) Identification Number; (g) Marital Status; 4 (h) Photographs; (i) Salary Information; and (j) Individual Tax Information. 8. Upon discovery of the Incident, Belden Inc. implemented, or has been in the process of implementing, the following remediation actions: (a) The following security measures: i. Conducted an audit of system administrator accounts to confirm that it was for valid users only (b) ii. Reviewed and developed plan to address incident closure activities iii. Improved relevancy and frequency of security awareness campaign. The following short-term and long-term containment actions: i. Roll out an endpoint security software to all server and client systems ii. Block command and control IP addresses on perimeter firewalls iii. Update existing security software definitions iv. Block access to Mega (cloud storage file hosting service) on firewalls v. Disallow syncing of data from internal systems to unapproved external cloud storage services vi. Remove unnecessary accounts from privileged security groups vii. Rebuild compromised systems viii. Reboot business-critical systems that cannot be rebuilt ix. Expedite patching of critical and high severity vulnerabilities 5 x. Reset passwords for Domains and Enterprise administrators xi. Reset passwords for all other privileged users xii. Reset the password for the Kerberos account xiii. Perform enterprise-wide password reset xiv. Ensured no direct remote access is available on the systems exposed to the Internet Findings and Basis for Determination 9. As a preliminary point, Belden Inc. is responsible for maintaining the security and integrity of the Belden Group’s systems (including its servers) and implementing the appropriate safeguards. However, the data protection obligations in the Personal Data Protection Act 2012 (“PDPA”) does not apply to Belden Inc., as it does not process personal data in Singapore. It is further noted that Belden Inc. has made reports to the relevant authorities in the jurisdictions where the compromised servers are located in. Therefore, no findings are made against Belden Inc. The Transfer Limitation Obligation under section 26 of the PDPA 10. Section 26(1) of the PDPA provides that an organisation shall not transfer any personal data to a country or territory outside Singapore except in accordance with requirements prescribed under the PDPA to ensure that organisations provide a standard of protection to personal data so transferred that is comparable to the protection under the PDPA (the “Transfer Limitation Obligation”). The relevant 6 requirements are prescribed in Part III of the Personal Data Protection Regulations 2014 (“PDPR”)1 . In particular: (a) Regulation 9(1)(b) of the PDPR requires an organisation that transfers personal data to a country or territory outside of Singapore to take appropriate steps to ensure that the recipient of personal data is bound by legally enforceable obligations (in accordance with Regulation 10) to provide to the transferred personal data a standard of protection that is at least comparable to that under the PDPA; (b) Regulation 10(1)(b) of the PDPR provides for contracts to be one such legally enforceable obligation. Regulation 10(2) in turn provides that such contract must require the recipient of the transferred personal data to provide a comparable standard of protection , and must specify the countries and territories to which the personal data may be transferred under the contract; and (c) Regulation 10(1)(c) of the PDPR provides binding corporate rules to be another such legally enforceable obligations. Regulation 10(3) in turn provides that such binding corporate rules require every recipient to provide a comparable standard of protection , and must specify (i) the recipients of the transferred personal data to which the binding corporate rules apply; (ii) the countries and 1 As the Incident occurred on or around September 2020, the Personal Data Protection Regulations 2014 apply. However, from 1 February 2021 onwards, the Personal Data Protection Regulations 2021 would apply. 7 territories to which the personal data may be transferred under the binding corporate rules; and (iii) the rights and obligations provided by the binding corporate rules. Further, such binding corporate rules may only be used by recipients that are related to the transferring organisation. 11. To comply with the Transfer Limitation Obligation in the context of an intra- group transfer where there is centralisation of corporate functions, group members involved in ongoing relationships for regular cross-border transfers of personal data out of Singapore are required to take reasonable steps to ascertain that the overseas transferee has implemented the appropriate policies, practices and / or technical measures to ensure that the transferred personal data is provided with the requisite level of protection. This is no different from an organisation’s obligation to carry out the necessary due diligence vis-à-vis the transfer of personal data to an overseas data intermediary, since the overseas transferee is a data intermediary even though they are members within the same group of companies. As stated in the Commission’s Advisory Guidelines on Key Concepts in the PDPA2: “Overseas transfers of personal data 6.22 Where an organisation engages a data intermediary to process personal data on its behalf and for its purposes, the organisation is responsible for complying with the Transfer Limitation Obligation in respect of any overseas transfer of personal data. This is regardless of whether the personal data is transferred by the organisation to an overseas data 2 Advisory Guidelines on Key Concepts in the PDPA (Rev 1 February 2021) 8 intermediary or transferred overseas by the data intermediary in Singapore as part of its processing on behalf and for the purposes of the organisation. 6.23 The Transfer Limitation Obligation requires that an organisation ensures that personal data transferred overseas is protected to a standard comparable with the Data Protection Provisions. The onus is on the transferring organisation to undertake appropriate due diligence and obtain assurances when engaging a data intermediary to ensure that it is capable of doing so. In undertaking its due diligence, transferring organisations may rely on data intermediaries’ extant protection policies and practices, including their assurances of compliance with relevant industry standards or certification.” Whether Belden Singapore complied with the Transfer Limitation Obligation 12. It is determined that Belden Singapore had not complied with the Transfer Limitation Obligation for the reasons explained below. 13. At the material time, Belden Inc. and certain other Belden entities had put in place a binding intra-group contract called the Global Data Transfer Agreement dated 1 September 2020 (“GDTA”), which governs the terms on which the various Belden entities transfer personal data to each other. 9 14. The GDTA contained provisions that required Belden Inc. to provide any personal data transferred from Singapore a comparable standard of protection to that under the PDPA at the time of the Incident. In particular: (a) Clause 5.2.2 provided that “Where Belden Data and/or Client Data originating in a Non-EEA territory (including in the United Kingdom, if at any time the United Kingdom is not in the EEA or beyond any transition period) (the Originating Territory”) are Processed in a territory which is different from the Originating Territory (the “Importing Territory”), then the Data Importer will Process such Belden Data and/or Client Data to a standard consistent with the Applicable Privacy Law(s) of the Originating Territory…” (b) Clause 19.5.5 of Schedule 5 required the data importer (i.e. Belden Inc.) to ensure that any transfer of personal data to a country or territory outside Singapore is provided a standard of protection that is comparable to the protection under the PDPA. 15. In addition to the above, the GDTA also contained provisions that require the transferee (the “Data Importer”) to implement measures aimed at addressing identified security risks to the personal data transferred and assisting the transferor (the “Data Exporter”) to comply with the relevant data protection laws. In particular: (a) Clause 4.1(c)(ii) required the Data Importer to “comply with any requirements arising under any Applicable Privacy Law(s) to protect the Belden and/or Client Data it received including, but not limited to the following: 10 (A) assistance, taking into account the nature of the Processing, by appropriate technical and organisation measures, insofar as this is possible, to fulfil any obligations the Data Exporter may have to respond to requests from data subjects to exercise their rights under Applicable Privacy Law(s) assistance; (B) assisting the Data Exporter as necessary to comply with its obligations under Applicable Privacy Law(s) including (without limitation) to conduct a data protection impact assessment and/or to consult with a Supervisory Authority, in each case taking into account the nature of the Processing and the information available to the Data Importer; and (C) not knowingly performing its obligations under this Agreement in such a way as to cause the Data Exporter to breach any of its obligations under Applicable Privacy Law(s); (D) ensuring the reliability of any persons it authorises to access the Belden and/or Client Data (including employees, agents and sub-Processors) and ensure that they have undergone appropriate training in the care, protection and handling of Belden and/or Client Data; (E) it will ensure that any persons authorised to process the Belden and/or Client Data have committed themselves to confidentiality or are under an appropriate statutory obligation of confidentiality; (F) it will maintain appropriate and sufficient technical and organisational security measures to protect such Belden and/or Client Data against a 11 Security Breach. Such measures will include as a minimum the Belden Security Measures; and (G) it will permit the Data Exporter such access to its premises, computer and other information systems, records, document and agreements as the Data Exporter may reasonably require to satisfy itself that the Data Importer is complying with its obligations under the Agreement; and (H) it will, at the choice of the Data Exporter, delete or return all Belden and/or Client Data to the Data Exporter after the end of the provision or services relating to processing, unless EU law or any EU Member State law requires storage of the Client Data.” (b) Clause 6 also required the Data Importer to carry out certain measures in the event of a security breach to investigate the breach, mitigate its effects and assist the Data Exporter to fulfill any obligations under the Applicable Privacy Law(s). 16. In this connection, the Belden Group has put in place the following policies and measures concerning the treatment of personal data: (a) Data Handling Standard – Governs the handling of electronic and physical data throughout the Belden Group; (b) Personal Data Handling Standard – Governs the handling of all forms of personal data throughout the Belden Group; 12 (c) Data Classification Policy – Sets the standards for protection of information assets from accidental or unlawful destruction, loss, unauthorised access, modification, compromise, disclosure or other misuse; and (d) Record Creation, Retention, Retrieval and Disposal Policy – Establishes requirements for creating, retaining, retrieving and disposing of records within the Belden Group. 17. Despite the suite of policies and technical measures adopted by the Belden Group, the GDTA and the above policies did not enable Belden Singapore to meet the requirements in Regulation 9(1)(b), read with Regulations 10(1)(b) and 10(2) when the Incident occurred: (a) The GDTA was not legally binding on Belden Singapore at the material time as Belden Singapore had not acceded to the GDTA. For Belden Singapore to be bound by the GDTA, it must have executed a Deed of Accension under Clause 12.1. However, at the time of the Incident, Belden Singapore had not executed such a Deed of Ascension. (b) Since the Belden Group opted to structure its data governance architecture around an intra-group contract (i.e. the GDTA), it is trite that the principle of privity of contracts applies, and only the parties to a contract are able to enforce the rights and obligations arising therein. Although the GDTA did, at the time of the Incident, require Belden Inc. to comply with the applicable standards under the PDPA while importing / processing personal data from Singapore (Clause 13 19.5.5 of Schedule 5), such obligations were not legally enforceable by Belden Singapore. Absent such a mechanism, Belden Singapore had no legal means to ascertain and ensure that the data transferred outside Singapore was afforded the same level of protection as under the PDPA. (c) Belden Singapore has acknowledged that this was a lapse. It subsequently rectified this oversight by signing a Deed of Accession on 18 June 2021. (d) Nevertheless, the investigations revealed that, in practice, all the relevant Belden group policies, practices and technical measures mentioned in paragraphs 14 to 16 were implemented in full to ensure that personal data transferred from Singapore are afforded a level of protection comparable to that provided under the PDPA. Therefore, Belden Singapore’s breach constituted a lapse in legal formalities rather than a failure to comply with the substance of the Transfer Limitation Obligation. Whether GVSPL complied with the Transfer Limitation Obligation 18. GVSPL was determined to have complied with the Transfer Limitation Obligation for the reasons explained below. 19. At the material time, GVSPL (as a subsidiary of GV USA) and Belden Inc. was bound by a Data Sharing Agreement dated 18 June 2020 (“DSA”), which governed the terms on which GVSPL transferred personal data to Belden Inc. The DSA is in compliance with Regulation 9(1)(b), read with Regulations 10(1)(b) and 10(2) of the 14 PDPR. Clause 10.1 of the DSA provided that, in the case of international transfers of data (including personal data): “The Receiving Party shall not process any Data (not permit any Data to be processed) in a territory outside of the European Economic Area (“EEA”) unless it has taken such measures as are necessary to ensure the transfer is in compliance with Applicable Data Protection Law3. Such measures may include (without limitation); (a) transferring the Data to a recipient in a country that the European Commission has decided provides adequate protection for personal data; (b) to a recipient that has achieved binding corporate rules authorisation in accordance with Applicable Data Protection Law; (c) to a recipient in the United States that maintains a valid and up-to-date EU-US Privacy Shield certification or (d) to a recipient that has executed standard contractual clauses adopted or approved by the European Commission or by virtue of entering into this Agreement.” 20. Whilst Clause 10.1 of the DSA does not mention the PDPA specifically, it does require a Grass Valley entity (including GVSPL) to take measures as are necessary to ensure the transfer is in compliance with the Applicable Data Protection Law, which – in the context of GVSPL – is the PDPA. Defined to mean “all worldwide data protection and privacy laws and regulations applicable to the personal data in question, including, where applicable, EU Data Protection Law.” 3 15 21. Additionally, the DSA also contains several provisions aimed at addressing identifiable security risks posed to the transferred personal data as well as ensuring that the Receiving Party assists the Disclosing Party. In particular: (a) Clause 6.1(c) required the Receiving Party to assist the Disclosing Party as necessary to comply with its obligations under the Applicable Data Protection Law (defined to mean all worldwide data protection and privacy laws and regulations application to the personal data in question) including (but not limited to) conducting any data protection impact assessments, consultation with a supervisory authority and fulfilment of any obligations the Disclosing Party may have to respond to requests from data subjects to exercise their rights under the Applicable Data Protection Law; (b) Clause 6.1(d) required the Receiving Party to ensure that any persons authorised to process the personal data to have committed themselves to confidentiality or are under an appropriate statutory obligation of confidentiality; and (c) Clause 7.1 provided that the Receiving Party “shall maintain appropriate and sufficient technical and organisational security measures to protect the Data against a Security Incident, taking into account state of the art, the costs of implementation and the nature, scope, context and purposes of processing, as well as the risks of varying likelihood and severity for the rights and freedoms of the data subject(s)”. Clause 7.2 further stipulates certain actions that the 16 Receiving Party is required to take in the event of a confirmed Security Incident to mitigate the effects of the incident and assist the Disclosing Party to fulfill any obligations under the Applicable Data Protection Law. 22. Finally, the group policies and measures concerning the treatment of personal data enumerated in paragraph 16 also applied to the transfers from GVSPL within the Belden Group. The Deputy Commissioner’s Decision 23. In light of Belden Singapore’s breach of the Transfer Limitation Obligation, the Commission is empowered under section 48I of the PDPA to issue Belden Singapore such directions as it deems fit to ensure compliance with the PDPA. This may include directing Belden Singapore to pay a financial penalty of such amount not exceeding $1 million as the Commission thinks fit. 24. In considering whether a direction should be given to Belden Singapore in this case, it is noted that: (a) It was an oversight that Belden Singapore did not sign a Deed of Accession prior to the Incident, and this lapse has been rectified by the signing of the Deed of Ascension. (b) Belden Singapore’s breach of the Transfer Limitation obligation was technical, and a failure of legal formalities that was not substantive in nature. As stated in paragraph 17(d), at the operational level, the suite of Belden group policies, 17 practices and technical measures implemented were sufficient to ensure that personal data transferred from Singapore to Belden Inc. were afforded a level of protection comparable to that provided under the PDPA. 25. Having considered all of the above circumstances, Belden Singapore is administered a warning in respect of its breach of the Transfer Limitation Obligation. No other directions are necessary in view of the remedial actions already taken, namely, Belden Singapore’s accession to the GDTA. YEONG ZEE KIN DEPUTY COMMISSIONER FOR PERSONAL DATA PROTECTION 18 ",Warning,a89e11d9b22ce2cc69d737938faf4e47ad9addbb,"[""tags"",""decision"",""pdf-url"",""description"",""date"",""timestamp"",""url"",""title"",""nature"",""pdf-content""]" 2023-10-01T11:02:10+08:00,fbd32491db44d3d0c97aa12a99cefd61ec954264,45,45,1,1016,Giordano was found not in breach of the PDPA in relation to an unauthorised network entry and ransomware infection that affected two of its systems storing personal data.,"[""Protection"", ""Not in Breach"", ""Wholesale and Retail Trade"", ""Ransomware"", ""Phishing""]",2021-11-11,https://www.pdpc.gov.sg/-/media/Files/PDPC/PDF-Files/Commissions-Decisions/Decision--Giordano-Originals-S-Pte-Ltd--151021.pdf,Protection,No Breach of the Protection Obligation by Giordano,https://www.pdpc.gov.sg/all-commissions-decisions/2021/11/no-breach-of-the-protection-obligation-by-giordano,2021-11-11,"PERSONAL DATA PROTECTION COMMISSION Case No. DP-2011-B7387 In the matter of an investigation under section 50(1) of the Personal Data Protection Act 2012 And Giordano Originals (s) Pte Ltd SUMMARY OF THE DECISION 1. On 3 December 2020, the Personal Data Protection Commission (the “Commission”) was notified by Giordano Originals (S) Pte Ltd (the “Organisation”) of an unauthorized network entry and ransomware infection at the OS and server level that occurred on or about 12 July 2020 (the “Incident”). 2. As a result of the Incident, two of the Organisation’s systems, one which stores the personal data of its employees and second, the personal data of its members were affected. 3. The Organisation’s own and independent investigation conducted found no sign of suspicious activity in the Singapore network, and no impact beyond the Singapore network. The unauthorised entry had most likely occurred through the use of compromised credentials obtained through phishing. 4. Personal data of 790,000 members and 184 employees in encrypted form were affected. The personal data of members comprised names (20% of the members), contact number and partial date of birth (without birth year). The personal data of employees comprised name, NRIC, address, gender, age, contact number, email address, educational and salary information. 5. Investigations revealed that the Organisation had in place reasonable security measures that are consistent with the recommendations that the Personal Data Protection Commission had made in our recent Handbook on “How to Guard Against Common Types of Data Breaches” on how to prevent malware or phishing attacks. The Organisation had installed and deployed various endpoint security solutions, which was complemented with real-time system monitoring for any Internet traffic abnormalities. Even before the Incident, the Organisation also conducted regular periodic system maintenance, reviews and updates (such as vulnerability scanning and patching). 6. More importantly, the Organisation had also ensured that its data was regularly and automatically backed-up, which was a key recommendation that the Commission made in our Handbook. 7. In addition, the Organisation had also taken steps to better protect the personal data affected by encrypting the personal data using current industry-standard RSA algorithm and passphrase. As a result, the personal data affected by the ransomware was not legible without decryption. 8. The Commission endorses the proper use of industry-standard encryption to protect personal data, and will give due weight to Organisations which have implemented the recommendations we made in our Handbook in determining whether an organisation has complied with its Protection Obligation under section 24 of the Personal Data Protection Act 2012 (the “PDPA”), or as a strong mitigation factor in the event of the Commission finds that there has been a breach of section 24 of the PDPA. 9. Following the Incident, the Organisation took prompt and extensive remedial both to mitigate the effects of the Incident and enhance the robustness of its security measures. This included increased frequency of staff phishing simulation trainings and security reviews as well as additional monitoring measures. There was no evidence of exfiltration of the personal data or decryption of the personal data. The Organisation was also able to fully restore the personal data from its backups. 10. In light of the reasons discussed above, the Deputy Commissioner for Personal Data Protection is satisfied that the Organisation had met its Protection Obligation under section 24 of the PDPA. In light of our findings, we will not be issuing any directions or taking any further enforcement action against the Organisation in relation to the Incident. ",Not in Breach,3967d62cd80927b7c190ce8deba0812d8d97eeb5,"[""tags"",""decision"",""pdf-url"",""description"",""date"",""timestamp"",""url"",""title"",""nature"",""pdf-content""]" 2023-10-01T11:02:10+08:00,fbd32491db44d3d0c97aa12a99cefd61ec954264,46,46,1,1016,"A financial penalty of $74,000 was imposed on Commeasure for failing to put in place reasonable security arrangements to prevent the unauthorised access and exfiltration of customers’ personal data hosted in a cloud database.","[""Protection"", ""Financial Penalty"", ""Accommodation and F&B""]",2021-11-11,https://www.pdpc.gov.sg/-/media/Files/PDPC/PDF-Files/Commissions-Decisions/Decision---Commeasure-Pte-Ltd---15092021.pdf,Protection,Breach of the Protection Obligation by Commeasure,https://www.pdpc.gov.sg/all-commissions-decisions/2021/11/breach-of-the-protection-obligation-by-commeasure,2021-11-11,"PERSONAL DATA PROTECTION COMMISSION [2021] SGPDPC 11 Case No. DP-2009-B7057 In the matter of an investigation under section 50(1) of the Personal Data Protection Act 201 And Commeasure Pte Ltd … Organisation DECISION Commeasure Pte Ltd. [2021] SGPDPC 11 Lew Chuen Hong, Commissioner — Case No. DP-2009-B7057 15 September 2021 Introduction 1 On 25 September 2020, the Personal Data Protection Commission (“the Commission”) received a data breach notification from Commeasure Pte Ltd (“the Organisation”) that its database containing 5,892,843 customer records had been accessed and exfiltrated (“the Incident”). The Organisation first found out about the data breach on 19 September 2020 when a cybersecurity company based in Atlanta, United States of America, approached the Organisation with an offer to contain the breach and retrieve the data from the hackers. The Commission commenced investigations into the Incident thereafter. Facts of the Case Background 2 The Organisation was incorporated in Singapore in 2014, and operates a hotel booking platform www.reddoorz.com which serves customers in the Southeast Asian region, such as Indonesia, Singapore, Philippines, Vietnam and Thailand. The Singapore office is primarily engaged in sales, finance and administrative activities, while all IT functions (including the management of the affected application package in this case) were managed by the Organisation’s subsidiary company, Commeasure Solutions India Pvt Ltd (“CPL India”). Cause of the Incident 3 Investigations revealed that the unknown threat actor(s) had most likely gained access and exfiltrated the Organisation’s database of customer records hosted in an Amazon RDS cloud database, after they obtained an Amazon Web Services (“AWS”) access key. The AWS 2 access key was embedded within an Android application package (“the affected APK”) publicly available for download from the Google Play Store. 4 This affected APK was created sometime in 2015, when the Organisation was still a start-up, and was last updated in January 2018. Even though the AWS access key had access to a “live” or production database, the AWS access key was embedded in the APK, and erroneously marked as a “test” key by the then-developers. With the exception of one of the Organisation’s co-founders and Chief Technology Officer, all the developers have since left the Organisation. Most unfortunately, even though the Organisation regarded this APK as “defunct”, the APK remained publicly available for download on the Google Play Store until the Organisation became aware of the Incident and removed the affected APK. 5 The fact that the Organisation had treated the affected APK as a “defunct” APK meant that even though the Organisation had engaged a cybersecurity company to conduct a security review and penetration testing sometime from September 2019 to December 2019, it was not within the scope of the security review or penetration tests. Consequently, the vulnerability was left undetected and exposed until the Organisation found out about the Incident. Likewise, even though the Organisation used “Proguard” on its current Android apps to prevent reverse engineering of APKs, which may have prevented the unknown threat actors from retrieving the AWS access key, the Organisation failed to review and deploy “Proguard” on the affected APK which it regarded as “defunct”. 6 As a result of the Incident, the Organisation’s database containing 5,892,843 customer records which included the customer’s name, contact number, email address, date of birth, a hashed password (encrypted with one-way BCrypt hash algorithm) used by the customer to access their “RedDoorz” account and their booking information was accessed and exfiltrated by unknown threat actor(s). Based on the Organisation’s investigations, the unknown threat actor(s) did not gain access or download the customers’ masked credit card numbers. Remedial actions 7 Following the Incident, the Organisation took the following remedial actions: a. CPL India immediately removed the affected APK from the Google Play Store; 3 b. The old access keys were invalidated and new access keys were created. The infrastructure and code repository access credentials were changed; c. IP blocking of suspicious traffic was enabled; and d. Informed all the affected customers via email on 26 September 2020 of the data breach, advising them to change their RedDoorz account password as an added precautionary measure, and to avoid using the same password on other digital platforms. 8 To prevent a recurrence of the Incident or similar incidents, the Organisation also took the following remedial actions: a. The Organisation amended its credential policy to clearly prohibit developers from embedding access codes in any code base; b. The Organisation upgraded their IT infrastructure to a private space for isolation of the customer database from the Internet. Only whitelisted IP addresses were allowed connection to ‘live’ databases; c. The Organisation separated the accounts for production and staging environments for all AWS services. Two-factor authentication was enabled for all tools and accounts used by developers. VPN-based control was implemented to access infrastructure resources; d. The Organisation configured alerts to capture mySQL dump query. Web application firewalls were set up. An audit of all user access to the AWS environment was conducted; and e. The Organisation appointed a cybersecurity company to conduct vulnerability assessment and penetration testing of all its existing applications. Findings and Basis for Determination Whether the Organisation contravened the Protection Obligation 4 9 Section 24 of the Personal Data Protection Act 2012 (“PDPA”) requires an organisation to protect personal data in its possession or under its control by making reasonable security arrangements to prevent unauthorised access, collection, use, disclosure, copying, modification, disposal or similar risks (the “Protection Obligation”). For the reasons set out below, the Organisation failed to implement reasonable security arrangements to protect the personal data in its control. 10 The Organisation collected the personal data of customers when they created a “RedDoorz” account through its hotel booking platform www.reddoorz.com. Even though the Organisation’s customer database was hosted using Amazon RDS on cloud, on servers physically located in North Virginia, United States of America, the database remained under the Organisation’s control throughout as the Organisation could access, use and remove the data. 11 In Re The Cellar Door Pte Ltd,1 we found that even though the organisation was not in direct possession of the personal data that was held in the data intermediary’s servers, it was still obliged to implement reasonable security arrangements to protect the personal data as it had control over such data. Likewise, even though AWS was responsible for the security of the cloud infrastructure that it provided to the Organisation, the Organisation bore ultimate responsibility under section 24 of the PDPA for making reasonable security arrangements to protect all the customers’ data under its control. 12 The data breach occurred because the Organisation embedded the AWS access key, which allowed access to the “live” or production database, in the APK. The root cause was therefore in the application, which was clearly within the Organisation’s responsibility. This presented a clear security risk. The AWS access key comprises of two parts, first, the access key ID, and second, the secret access key, and was effectively the Organisation’s username and password. In a webpage titled “Best practices for managing AWS access keys”, AWS advised users to protect the access keys as “anyone who has the access keys for your AWS account root user has unrestricted access to all resources in your AWS account” 2. AWS also cautioned users not to “embed access keys directly into code”, which was exactly what the Organisation 1 [2017] PDP Digest 160. 2 https://docs.aws.amazon.com (last accessed on 6 August 2021). 5 had done in the present case. We therefore find the Organisation in breach of section 24 of the PDPA for reflecting the AWS access key in the affected APK. 13 In the course of investigations, the Organisation explained that its failure to implement sufficiently robust processes to manage its inventory of infrastructure access keys was attributable to the high turnover of its employees from the time of its inception to the discovery of the Incident. This explanation is unacceptable, however sympathetic one might be to the human resource issues that the Organisation had to manage. The Organisation’s responsibility to protect personal data in its control or possession commences ought not to have been subjected to staff movement or appointment. 14 In Re WTS Automotive Services Pte Ltd,3 we highlighted the importance of conducting a “regular review to ensure that the website collecting personal data and the electronic database storing the personal data has reasonable security arrangements to prevent unauthorised access, collection, use, disclosure, copying, modification, disposal or similar risks” as the “personal data of individuals may be exposed if the website or database in which it is stored contains vulnerabilities”.4 The Commission reiterates that it is necessary for an organisation to “[c]onduct regular ICT security audits, scans and tests to detect vulnerabilities”.5 15 In this case, the Organisation conducted internal security testing and application architecture reviews every quarter and had engaged a cybersecurity company to conduct a security review and penetration testing sometime from September 2019 to December 2019. The Organisation admitted however, that it “overlooked” including the affected APK in the security review as it was “old”. In addition, the Organisation admitted that the AWS access key had been mistakenly marked as a “test key”. This resulted in its omission from the security review as well as from the Organisation’s periodic review of accounts and login credentials. 16 It is important to highlight that the Organisation remained responsible for the affected APK. The Organisation’s failure to include the affected APK and the AWS access key within the scope of the security review arose because of the Organisation’s negligence to include them 3 [2019] PDP Digest 317. 4 Personal Data Protection Commission, Guide to Data Protection Impact Assessments (1 November 2017) at para. 8.3. 5 Personal Data Protection Commission, Guide to Securing Personal Data in Electronic Medium (revised 20 January 2017) at para. 6.1. 6 in its inventory of IT assets in production after the Organisation had wrongly labelled the affected APK as “defunct” and the AWS access key as a “test” key. 17 Accordingly, we are not satisfied that the IT security reviews that the Organisation conducted were sufficiently rigorous, and met the standard required under section 24 of the PDPA. We are therefore of the view that the Organisation has breached section 24 of the PDPA for failing to include the affected APK and AWS access key in the Organisation’s security reviews. If a security review had examined the affected APK or the AWS access key, the vulnerability exposed by the embedded AWS access key would have been discovered, and the Incident could have been prevented. The Commission’s Directions 18 In determining whether to impose a financial penalty on the Organisation pursuant to section 48J(1) of the PDPA, and if so, the amount of such financial penalty, we took into account the factors listed at section 48(6) of the PDPA. The Commission notes that the data breach affected 5,892,843 individuals whose personal data was exfiltrated. This is the largest data breach that has occurred since the PDPA came into effect. Further, prior to the exfiltration of the data in September 2020, the affected APK with the embedded AWS access key had remained publicly available for download on the Google Play Store for a significant duration of time. A lengthy period of 2 years and 9 months passed from the time the Organisation made its last update to the affected APK in January 2018 to 19 September 2020, when the Organisation finally found out about the data breach. 19 Having said that, the Commission also took into account the following mitigating factors: (a) The Organisation was cooperative in the course of investigations and had provided prompt responses to PDPC’s requests for information; (b) The Organisation implemented remedial actions to address the Incident; and (c) The Organisation had conducted periodic security reviews which promised to offer some data protection, albeit their efforts were ultimately futile as these security reviews did not include the affected APK. 7 20 In deciding the amount of financial penalty to be imposed, we also considered that the Organisation, which operates in the hospitality industry, had been severely impacted by the COVID-19 pandemic. Having considered all the relevant factors of this case, the Commissioner hereby requires the Organisation to pay a financial penalty of $74,000 within 30 days from the date of the relevant notice accompanying this decision, failing which interest at the rate specified in the Rules of Court6 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. YEONG ZEE KIN DEPUTY COMMISSIONER FOR COMMISSIONER FOR PERSONAL DATA PROTECTION 6 Cap 322, R5, 2014 Rev Ed. 8 ",Financial Penalty,07efcafd13b2f83b14c9de466d3a142032ed8020,"[""tags"",""decision"",""pdf-url"",""description"",""date"",""timestamp"",""url"",""title"",""nature"",""pdf-content""]" 2023-10-01T11:02:10+08:00,fbd32491db44d3d0c97aa12a99cefd61ec954264,47,47,1,1016,"A financial penalty of $10,000 was imposed on ChampionTutor for failing to put in place reasonable security arrangements to protect personal data in its possession. The incident resulted in the personal data being exposed.","[""Protection"", ""Financial Penalty"", ""Education""]",2021-10-14,https://www.pdpc.gov.sg/-/media/Files/PDPC/PDF-Files/Commissions-Decisions/Decision--ChampionTutor-Inc-Private-Limited--10082021.pdf,Protection,Breach of the Protection Obligation by ChampionTutor,https://www.pdpc.gov.sg/all-commissions-decisions/2021/10/breach-of-the-protection-obligation-by-championtutor,2021-10-14,"PERSONAL DATA PROTECTION COMMISSION Case No. DP-2103-B7984 In the matter of an investigation under section 50(1) of the Personal Data Protection Act 2012 And ChampionTutor Inc. (Private Limited) SUMMARY OF THE DECISION 1. On 24 February 2021, the Personal Data Protection Commission (the “Commission”) received information that ChampionTutor Inc. (Private Limited)’s (the “Organisation”) database, containing personal data of individuals, was being sold on dark web (the “Incident”). 2. The Organisation was not aware of the Incident until it was notified by the Commission. The cause of the Incident was suspected to be SQL injection of the Organisation’s website. The Organisation knew about this SQL injection vulnerability when it conducted a penetration test in December 2020. The Organisation had instructed its developer, based in India, to fix the vulnerability. However, the developer did not act on the request and this vulnerability was left unfixed until the Incident happened. 3. As a result, the personal data of 4,625 students were affected. The personal data included name, email address, contact number and address. 4. The Organisation took the following remedial measures after the Incident: a. Engaged a new team of developers to fix all the SQL injection vulnerabilities; b. Parameterised SQL statements by disallowing data-directed context changes to prevent SQL injection attacks from resurfacing; and c. Is in the process of revamping the entire website source codes to reduce possible vulnerabilities. 5. The Organisation admitted to having breached the Protection Obligation under section 24 of the Personal Data Protection Act (the “PDPA”), and requested for the matter to be dealt with in accordance with the Commission’s Expedited Decision Procedure. 6. The Organisation admitted it was aware of the SQL injection vulnerability in December 2020. Yet, the Organisation failed to take active steps to fix the vulnerability even when its developer was not responsive, purportedly due to the COVID-19 pandemic, and the Organisation left the vulnerability unresolved until the Incident happened. 7. In the circumstances, the Organisation is found to have breached section 24 of the PDPA. 8. On 14 July 2021, the Organisation was notified of the Commission’s intention to impose a financial penalty based on the Commission’s consideration of the factors listed under section 48J(6) of the PDPA, and the circumstances of this case, in particular (i) the Organisation’s upfront voluntary admission of liability which significantly reduced the time and resources required for investigations; and (ii) the prompt remedial actions undertaken by the Organisation. The Organisation was invited to make representations. 9. Having considered the Organisation’s representations dated 28 July 2021, the Deputy Commissioner hereby directs the Organisation to pay a financial penalty of $10,000 in 12 instalments by the due dates as set out in the accompanying notice, failing which the full outstanding amount shall become due and payable immediately and interest at the rate specified in the Rules of Court in respect of judgment debts shall accrue and be payable on the outstanding amount of such financial penalty until the financial penalty is paid in full. 10. In view of the remedial actions taken by the Organisation, the Commission will not issue any directions under section 48I of the PDPA. ",Financial Penalty,001064522a1c6277a0c24b9cf1a09495440cf2e8,"[""tags"",""decision"",""pdf-url"",""description"",""date"",""timestamp"",""url"",""title"",""nature"",""pdf-content""]" 2023-10-01T11:02:10+08:00,fbd32491db44d3d0c97aa12a99cefd61ec954264,48,48,1,1016,A warning was issued to The National Kidney Foundation for failing to put in place reasonable security to protect the personal data in its possession. The incident resulted in personal data being downloaded.,"[""Protection"", ""Warning"", ""Healthcare"", ""Phishing"", ""Email""]",2021-10-14,https://www.pdpc.gov.sg/-/media/Files/PDPC/PDF-Files/Commissions-Decisions/Decision---The-National-Kidney-Foundation---15092021.pdf,Protection,Breach of the Protection Obligation by The National Kidney Foundation,https://www.pdpc.gov.sg/all-commissions-decisions/2021/10/breach-of-the-protection-obligation-by-the-national-kidney-foundation,2021-10-14,"PERSONAL DATA PROTECTION COMMISSION [2021] SGPDPC 10 Case No DP-2005-B6353 In the matter of an investigation under section 50(1) of the Personal Data Protection Act 2012 And The National Kidney Foundation … Organisation DECISION The National Kidney Foundation [2021] SGPDPC 10 Yeong Zee Kin, Deputy Commissioner — Case No. DP-2005-B6353 15 September 2021 Introduction 1 On 22 May 2020, the Personal Data Protection Commission (the “Commission”) received a data breach notification from the National Kidney Foundation (the “Organisation”). The Organisation had discovered that on 17 May 2020, a hacker had gained access to the work email account of one of its employees (“Employee A”) and had likely exfiltrated the personal data contained in the email account (the “Incident”). Background 2 The Organisation is a prominent non-profit health organisation in Singapore that provides health services, including subsidised kidney dialysis. Employee A is an executive in the Organisation’s Clinical Operations department. which deals with implementation of operations policies, budget planning and working with medical and nursing management team to uphold healthcare standards. The Incident 3 Investigations revealed that, on 14 May 2020, Employee A received a phishing email containing a hyperlink to a website with a further link to another website seeking his account credentials. The hacker is believed to have obtained Employee A’s account credentials in this way. Thereafter, the hacker accessed Employee A’s email account (the “Email Account”) and synchronised the mailbox on 17 May 2020. In doing so, the hacker is believed to have downloaded all the data stored in the Email Account in its entirety. The hacker also used Employee A’s email account to send phishing emails to 1,039 external business contacts of the Organisation, and 9 email accounts belonging to persons within the Organisation. Whilst these 1 phishing emails contained a link to a phishing webpage, they did not disclose any personal data collected from the Email Account. 4 The Email Account comprised of 23,145 emails containing the personal data of approximately 500 individuals (i.e. patients, employees and third parties): (a) Age (b) Arrear sum owed (22 patients affected) (c) Bank account number (d) Curriculum vitae (e) Date of birth (f) Data subject access request form (for 1 Singapore Police Force officer) (g) Information on the patient's family status and any psycho-social issues faced by the patient (h) Dialysis readings (i) Email address (j) Emergency contact numbers of nurses (k) Education certificate(s) (l) Foreign Identification Number (m) Headshot photo (n) Health screening virology report of the Organisation’s nurses (25 nurses affected) (o) Household income band (p) Marriage certificate; and (q) Medical condition (8 patients affected) (collectively, the “Affected Data”) Security Measures prior to the Incident 2 5 At the time of the Incident, the work email accounts of the Organisation’s employees were hosted on Microsoft Office 365, and the employees were able to access their email accounts through the internet via a browser, ie web-accessible email or webmail. The following security arrangements were in place to protect the email accounts from unauthorised access: (a) The password policy requires a minimum of 8 alphanumeric characters, including upper and lower cases, and a special symbol. (b) A maximum of 3 unsuccessful login attempts before email accounts were locked out. (c) Deployed Microsoft’s Advanced Threat Protection (“ATP”) email filtering service, with the ATP anti-phishing feature turned on. (d) Deployed Sender Policy Framework (“SPF”) and Domain Keys Identified Mail (“DKIM”) email authentication protocols. 6 In addition, the Organisation also had various storage protection and network protection measures. This included a web isolation tool from Menlo Security, and an appointed Managed Security Service Provider (“MSSP”) that performs security monitoring round the clock. 7 In relation to its employees, the Organisation implemented a range of measures to increase data protection awareness, including: (a) Issuing a policy manual which defined the standards for proper usage of all computing and network resources by employees, and how employees should handle suspicious emails; (b) Conducted training workshops in 2017 and 2018 in relation to the Personal Data Protection Act 2012 (“PDPA”) for its internal stakeholders, which included a segment on cybersecurity covering the topic of suspicious emails; (c) Conducting a phishing simulation exercise in 2019, which Employee A participated in; (d) E-learning modules on cyber-security and the PDPA, which Employee A completed in March 2020; 3 (e) Sending regular emails and alerts targeted at increasing cybersecurity awareness to its employees; and (f) Deploying cybersecurity awareness screensavers on all of the Organisation’s computers. Remedial Measures 8 After the Incident, the Organisation carried out the following remedial and rectification measures: (a) Implemented additional email account security requirements for webmail access in the form of two-factor authentication (“2FA”) on 22 May 2020; (b) Appointed a third-party service provider to conduct daily scans for communication relating to the Incident on platforms across all media; and (c) Notified affected individuals of the Incident on 24 July 2020 and offered the affected individuals subscription to an identity theft service to identify trading or selling of their personal data on the dark web. Findings and Basis for Determination Whether the Organisation had contravened section 24 of the PDPA 9 Based on the circumstances of the Incident as set out above, the Commission’s investigation centred on whether the Organisation had breached its obligation under section 24 of the PDPA to protect personal data in its possession or under its control by taking reasonable security steps or arrangements to prevent unauthorised access, collection, use, disclosure, copying, modification, disposal or similar risks (“Protection Obligation”). 10 For the reasons set out below, it is determined that the Organisation failed to implement reasonable security arrangements to protect the Affected Data from the risk of unauthorised access by failing to implement reasonable access controls to its employees’ webmail accounts. 11 In determining what constitutes reasonable security steps or arrangements, an organisation should have regard to the nature of the personal data in its possession and control, 4 as well as the impact that the disclosure of the data might have on the affected persons. As stated in the Commission’s Advisory on Key Concepts in the PDPA1: “There is no ‘one size fits all’ solution for organisations to comply with the Protection Obligation. Each organisation should consider adopting security arrangements that are reasonable and appropriate in the circumstances, for example, taking into consideration the nature of the personal data, the form in which the personal data has been collected (e.g. physical or electronic) and the possible impact to the individual concerned if an unauthorised person obtained, modified or disposed of the personal data. For example, in the employment context, it would be reasonable to expect a greater level of security for highly confidential employee appraisals as compared to more general information about the projects an employee has worked on. In practice, an organisation should: a) design and organise its security arrangements to fit the nature of the personal data held by the organisation and the possible harm that might result from a security breach; b) identify reliable and well-trained personnel responsible for ensuring information security; c) implement robust policies and procedures for ensuring appropriate levels of security for personal data of varying levels of sensitivity; and d) be prepared and able to respond to information security breaches promptly and effectively. In addition, it might be useful for organisations to undertake a risk assessment exercise to ascertain whether their information security arrangements are adequate. In so doing, the following factors may be considered: a) 1 the size of the organisation and the amount and type of personal data it holds; See sections 17.2 – 17.3 of Advisory Guidelines on Key Concepts in the PDPA (Rev 1 February 2021) 5 b) who within the organisation has access to the personal data; and c) whether the personal data is or will be held or used by a third party on behalf of the organisation.” (emphasis added) 12 Where the personal data held by the organisation or particular employees are sensitive and may cause damage to affected individuals if compromised, strong access control measures, including robust authentication measures, are important safeguards. On top of basic authentication measures such as implementing a proper password policy and password expiration mechanism, strengthened measures such as two-factor authentication (“2FA”) should be considered for webmail accounts with sensitive personal data, such as personal data relating to health and finances. As stated at paragraphs [7.3] and [7.4] of the Commission’s Guide to Securing Personal Data in Electronic Medium2: “7. 3. The strength of authentication, such as password requirements or other mechanisms for access to personal data, should depend on the potential damage to the individual, such as potential damage to reputation or finances, if such personal data is compromised… 7.4 More secure authentication methods include two-factor or multi-factor authentication. These involve the use of a combination of information that the user knows, such as a password or PIN, and an object that only the user possesses, such as a digital key, token or smart card, or a unique physical trait, such as the use of fingerprints in biometric technology. The use of multi-factor authentication increases confidence in the identity of the user accessing the system.” [emphasis added] 13 Having regard to the nature of personal data handled by the Organisation in its daily operations, it had higher-level security needs that had to be met when discharging its Protection Obligation. The Organisation is one of Singapore’s most prominent non-profit health organisations and a key provider of subsidised dialysis treatment, with a significant number of 2 Guide to Securing Personal Data in Electronic Medium (revised Jan 2017) 6 patients under its care. Given the nature of its operations, the Organisation’s employees routinely handle the medical data of its patients and financial data relating to the processing of patient subsidies. The vulnerability of its employees’ email accounts (including the Email Account) is made more acute by the fact that they are web-accessible. In this regard, the Organisation should have conducted a risk assessment to identify the employee email accounts that warranted a more robust authentication process by virtue of the sensitivity of the personal data expected to be received in or sent from their email accounts. 14 As stated at 4 above, the Email Account contained the personal data of approximately 500 individuals. A subset of the Affected Data included sensitive personal data such as the medical conditions of patients, arrears owed and health screening virology reports of some of the Organisation’s nurses. In this regard, even though the Organisation did put in place a host of technical measures and processes to address phishing risks prior to the Incident, we are of the view that these security steps and arrangements did not satisfy the standard required under section 24 of the PDPA, , for the reasons set out below, especially when the nature of the personal data routinely handled by the Organisation is considered. 15 First, the Organisation did not adopt a risk-based approach to identify employees whose roles and functions required them to handle sensitive personal data and strengthen the access control measures to their email accounts. 16 Second, in relation to the email accounts of the employees who handle sensitive personal data (in particular, Employee A) in their daily work, the Organisation also did not implement more secure authentication processes access control measures to their email accounts prior to the Incident. As stated in paragraph 5, the Organisation’s access control requirements were confined to a password policy and the locking out of email accounts after 3 unsuccessful login attempts. These measures are too basic and inadequate to safeguard webmail accounts from the threat of hackers seeking to access them from the internet, and left the personal data contained therein vulnerable to unauthorised access and exfiltration. Examples of more secure authentication methods include 2FA, which the Organisation eventually implemented only after the Incident had occurred. If 2FA had been implemented earlier, this would have ensured that the use of stolen credentials such as passwords would not, per se, be sufficient to access the account. 7 17 In the premises, the Organisation has breached the Protection Obligation. The Deputy Commissioner’s Decision 18 In determining whether any directions should be imposed on the Organisation under section 48I of the PDPA, and/or whether the Organisation should be required to pay a financial penalty under section 48J of the PDPA, the Commission considered the factors listed at section 48J(6) of the PDPA, and gave particular weight to the following mitigating factors: Mitigating Factors (a) The Organisation had cooperated fully with the Commission during its investigations; (b) The Organisation had put in place extensive measures to prevent phishing and educate its employees about data protection; (c) The Organisation took prompt remedial actions following the Incident, including notification of the affected individuals; and (d) The Organisation had conducted various data protection and cybersecurity training for its employees. 19 Having considered all the mitigating factors listed above, the Organisation is administered a warning in respect of its breach of the Protection Obligation. No other directions are necessary in view of the remedial actions already taken by the Organisation. YEONG ZEE KIN DEPUTY COMMISSIONER FOR PERSONAL DATA PROTECTION 8 ",Warning,4095cd546dacd60ce1e477d8e6d816e126775088,"[""tags"",""decision"",""pdf-url"",""description"",""date"",""timestamp"",""url"",""title"",""nature"",""pdf-content""]" 2023-10-01T11:02:10+08:00,fbd32491db44d3d0c97aa12a99cefd61ec954264,49,49,1,1016,Directions were issued to J & R Bossini Fashion for breaches of the PDPA in relation to the transfer of Singapore-based individuals’ personal data to its parent company in Hong Kong and the protection of its employees’ personal data stored in its servers in Singapore.,"[""Protection"", ""Transfer Limitation"", ""Directions"", ""Wholesale and Retail Trade""]",2021-10-14,https://www.pdpc.gov.sg/-/media/Files/PDPC/PDF-Files/Commissions-Decisions/Decision---J--R-Bossini-Fashion-Pte-Ltd---18082021.pdf,"Protection, Transfer Limitation",Breach of the Protection and Transfer Limitation Obligations by J & R Bossini Fashion,https://www.pdpc.gov.sg/all-commissions-decisions/2021/10/breach-of-the-protection-and-transfer-limitation-obligations-by-j-r-bossini-fashion,2021-10-14,"PERSONAL DATA PROTECTION COMMISSION [2021] SGPDPC 9 Case No. DP-2006-B6440 In the matter of an investigation under section 50(1) of the Personal Data Protection Act 2012 And J & R Bossini Fashion Pte Ltd … Organisation DECISION J & R Bossini Fashion Pte Ltd [2021] SGPDPC 9 Yeong Zee Kin, Deputy Commissioner — Case No. DP-2006-B6440 18 August 2021 Introduction 1 On 13 June 2020, J & R Bossini Fashion Pte Ltd (“the Organisation”) notified the Personal Data Protection Commission (“the Commission”) of a ransomware attack which had affected the IT systems of the Organisation’s group of companies on or around 27 May 2020 (“the Incident”). The Commission commenced investigations to determine whether the circumstances relating to the Incident disclosed any breaches by the Organisation of the Personal Data Protection Act 2012 (“PDPA”). Facts of the Case 2 The Organisation is a company incorporated in Singapore, and a subsidiary of Bossini International Holdings Limited, a company listed on the Stock Exchange of Hong Kong (“Bossini Holdings”). Bossini Holdings and its subsidiaries (“the Group”) are in the business of garment retail and brand franchising. 3 The Group’s IT systems and infrastructure across different regions (including Singapore) are centrally managed by Bossini Holdings from Hong Kong. While most of the Group’s production servers are located in Hong Kong, at the material time, the Organisation maintained two servers and various workstations for its staff in Singapore which were connected to the Group’s network in Hong Kong by way of a virtual private network (“VPN”). 2 Personal data collected by the Organisation 4 Sometime prior to 2017, the Organisation collected personal data from customers and prospective customers in Singapore for the purposes of administering a customer loyalty programme. The personal data collected comprised of each individual’s: (a) Name; (b) NRIC number, (c) Phone number, (d) Email address, (e) Residential address, (f) Date of birth; and (g) Gender. (collectively, “the Customer Data”) 5 The Customer Data was initially stored locally by the Organisation in its servers in Singapore. The Organisation transferred the Customer Data out of Singapore to a server in Hong Kong around July 2017, as part of a Group level consolidation exercise with a view to hosting the data in a cloud environment in the future. 6 Other than the Customer Data, the Organisation also collected and stored personal data pertaining to its employees in its Singapore servers. This included each employee’s: 3 (a) Name; (b) NRIC number, (c) Phone number, (d) Email address, (e) Residential address, (f) Date of birth; (g) Gender; (h) Marital status; (i) Salary details; (j) Bank account details, and (k) Medical claims records. (collectively, “the Employee Data”) The Incident 7 Sometime before 27 May 2020, attackers gained access to the Group’s network in Hong Kong by exploiting a vulnerability in the Group’s off-the-shelf VPN software. The vulnerability allowed the attackers to extract valid VPN credentials and bypass the Group’s perimeter network security measures. 4 8 The vulnerability exploited by the attackers had been fixed by a patch released by the VPN software developer in September 2019. However, Bossini Holdings had not deployed the patch for the Group as at the time of the Incident on 27 March 2020 (i.e. nine months later). The patch was subsequently deployed after the Incident on 3 June 2020. 9 After gaining a foothold into the Group’s network in Hong Kong, the attackers moved laterally across the Group and compromised various administrative and user accounts to conduct reconnaissance and escalate privileges. Eventually, with Group-level administrative privileges, the attackers disabled endpoint security systems across the Group and executed the ransomware attack. 10 The personal data of approximately 200,000 of the Group’s customers stored in the Hong Kong server was encrypted and rendered inaccessible in the Incident. Relevantly, this included the Customer Data of 154,213 customers originally collected by the Organisation in Singapore. Of this, the Customer Data of at least 14,082 Singapore customers was exfiltrated and exposed on the dark web. The Employee Data of 120 of the Organisation’s employees stored in the servers in Singapore was similarly encrypted and rendered inaccessible in the Incident. 11 All backups of the Customer Data and Employee Data maintained by Bossini Holdings and the Organisation were affected and encrypted in the Incident, and no data restoration was possible. Remedial actions 12 Following the Incident, the remedial actions of Bossini Holdings and the Organisation included: 5 (a) Appointing a leading cybersecurity vendor to contain the impact of the Incident and investigate its causes; (b) Publishing a data breach announcement on the Group’s website and via the Stock Exchange of Hong Kong; (c) Notifying affected customers via the email addresses provided when registering for the customer loyalty programme; (d) Blocking the IP addresses used by the attackers in the Incident and restricting outbound network traffic to limit the ability of any malware in the Group’s network to “call back” to the attackers; (e) Upgrading the VPN software to patch the vulnerability; (f) Enforcing multi-factor authentication for all remote access via VPN; (g) Enforcing a password change for all user account passwords and resetting all domain user credentials; (h) Performing a review to limit and restrict public-facing services on network perimeters; (i) Performing vulnerability scanning for critical servers to identify and rectify immediate risks; (j) Reviewing and enhancing endpoint protection tools; (k) Implementing monitoring of perimeter firewalls and planning upgrades to the server firewalls; and 6 (l) Engaging a third-party security operations centre to monitor the Bossini group’s network infrastructure. 13 For completeness, the Privacy Commissioner for Personal Data, Hong Kong (“PCPD”) was notified of the Incident by Bossini Holdings on 24 June 2020 and conducted its own compliance check. The Commission was informed that the PCPD would not be proceeding with any further investigations after considering the circumstances of the case and the remedial measures taken by Bossini Holdings. Findings and Basis for Determination 14 Based on the circumstances of the Incident, the Commission’s investigation focused on: (a) Whether the Organisation had breached its obligation under section 26 of the PDPA to transfer personal data to a country or territory outside Singapore in accordance with requirements prescribed under the PDPA (the “Transfer Limitation Obligation”) in respect of the Customer Data transferred to Hong Kong on 17 July 2017; and (b) Whether the Organisation had breached its obligation under section 24 of the PDPA to protect personal data in its possession or under its control by making reasonable security arrangements to prevent unauthorised access, collection, use, disclosure, copying, modification, disposal or similar risks (the “Protection Obligation”) in respect of the Employee Data encrypted in the Organisation’s servers in Singapore during the Incident. 15 For the reasons set out below, the Organisation was determined to have breached both the Transfer Limitation and Protection Obligations. 7 16 As a preface to the discussion below, it is relevant to highlight that both of the Organisation’s breaches were attributable to its failure to implement policies and practices to meet its obligations under the PDPA, as required by section 12 of the PDPA (“the Accountability Obligation”). 17 For corporate groups which engage in (i) centralisation of corporate functions involving intra-group dataflows and/or (ii) “outsourcing” of data processing activities to another member of the same group, policies and practices ought to be developed and implemented at the group level for the benefit of all members of the group. As stated in Everlast Projects Pte Ltd and others [2020] SGPDPC 20 (“Everlast”) at [13]: “(O)rganisations operating as a group of companies may comply with the Accountability Obligation through binding group-level written policies or intra-group agreements that set out a common and binding standard for the protection of personal data across all organisations in the same corporate group. These binding group-level written policies or intra-group agreements are akin to binding corporate rules (“BCRs”) imposed by an organisation on its overseas recipient of the personal data (in compliance with the Transfer Limitation Obligation under Section 26(1) of the PDPA), which oblige the overseas recipient to provide a standard of protection to the transferred personal data that is at least comparable to that under the PDPA. When the corporate group is a multinational corporation (“MNC”) and the Contracting Organisation (i.e. a member of a corporate group) transfers personal data to an overseas Servicing Organisation (i.e. an overseas member of the same corporate group), the binding group-level written policies, intra-group agreements or BCRs which meet the requirements of the Protection Obligation under section 24 of the PDPA 8 would also meet the requirements of section 26(1) of the PDPA (i.e. the Transfer Limitation Obligation)” Whether the Organisation breached the Transfer Limitation Obligation 18 As the Customer Data was transferred from Singapore to Hong Kong on 17 July 2017, the requirements in Part III of the Personal Data Protection Regulations 2014 (“PDPR”) 1 governed the Organisation’s compliance with the Transfer Limitation Obligation. 19 Regulation 9(1)(b) of the PDPR requires an organisation that transfers personal data outside of Singapore to take appropriate steps to ensure that the recipient of the personal data is bound by legally enforceable obligations to provide the transferred personal data a standard of protection at least comparable to that under the PDPA. Under regulation 10 of the PDPR, such legally enforceable obligations can be imposed on the recipient organisation under (a) any law (e.g. the law of the recipient country); (b) any contract between the parties2; (c) binding corporate rules3; or (d) any other legally binding instrument. 20 In the present case, the Organisation transferred the Customer Data to Bossini Holdings upon instruction and took no steps to ascertain whether the Customer Data would be accorded a comparable level of protection. In this regard, the transfer of the Customer Data was not made pursuant to any intra-group contracts, binding corporate rules, or other legally binding instrument. Accordingly, the Organisation failed to comply with regulation 9(1)(b) of the PDPR and was determined to have breached the Transfer Limitation Obligation. 1 For transfers which took place on or after 1 February 2021, the relevant requirements are those prescribed in Part 3 of the Personal Data Protection Regulations 2021. 2 For example, see Cigna Europe Insurance Company S.A.-N.V. [2019] SGPDPC 18. 3 For example, see Singapore Technologies Engineering Limited [2020] SGPDPC 21. 9 Whether the Organisation breached the Protection Obligation 21 At the time of the Incident, Bossini Holdings had implemented group-level security arrangements for all of the Group’s IT systems, including the Organisation’s servers in Singapore. Notwithstanding, the Employee Data remained in the Organisation’s possession in the servers in Singapore, and the Organisation bore the Protection Obligation in respect of the same. 22 It is appreciated that a corporate subsidiary in the circumstances of the Organisation, which is subject to group-level security arrangements managed centrally, may not have the autonomy or power to respond independently to a multinational data breach incident. Nevertheless, the standard of conduct expected of such organisations in order to comply with the Protection Obligation is not onerous. The following principles have been established in past decisions. (a) First, a subsidiary should not adopt group level data protection policies without considering whether these need to be adapted to their circumstances and contexts: Tiger Airways Singapore Pte Ltd and others [2017] SGPDPC 6 at [33]; and (b) Second, when there is centralisation of corporate functions, group level policies should be put in place in order that roles and responsibilities are clear: Everlast. 23 These twin principles provide the guard rails to guide organisations for establishing accountability within a group and how this should cascade. In gist, where there is centralisation of corporate functions, group level policies establish the scope of centralisation and the respective roles and responsibilities of members within the group. This is not dissimilar to a situation in which a data controller outsources certain data protection responsibilities to an external vendor. It is the data controller’s obligation to specify and document what 10 responsibilities the vendor has undertaken, failing which they remain those of the data controller. Once the group level policies are established, the relevant content then needs to be cascaded and adapted in the internal policies implemented by each member of the group at an organisational level. 24 As a subsidiary in a multinational corporate group, it is accepted that the Organisation had to implement the Group’s IT policies, including IT security practices. The reality is that its ability to influence these IT policies and how these practices were implemented was likely to also have been limited. Nevertheless in the present case, the Group had no group level policies, intra-group agreements, or binding corporate rules spelling out the data protection responsibilities of the respective members of the Group. This created uncertainty as to whether Bossini Holdings or the Organisation was responsible for software patching and security testing of the Organisation’s IT systems in Singapore. 25 It was also accepted that the security lapse and privilege escalation that enabled the attackers to overcome the Organisation’s endpoint protections in the Incident occurred abroad out of the control of the Organisation. If the Group had intended for Bossini Holdings to be centrally responsible for developing, implementing, and maintaining security arrangements for all of the Group’s IT systems (including those of the Organisation), this should have at least been documented in a binding group-level written policy. There was no evidence of the same, and accordingly, the Organisation continued to bear responsibility in relation to the Employee Data in its possession. 26 In the circumstances, the Organisation was determined to have breached the Protection Obligation. 11 The Deputy Commissioner’s Directions 27 Having considered all the relevant factors of this case, the Deputy Commissioner hereby directs the Organisation to: (a) within 30 days from the date of the direction accompanying this decision, put in place intra-group agreements, contracts, or binding corporate rules for compliance with sections 24 and 26 of the PDPA; and (b) inform the Commission of the completion of the above within 7 days of implementation. YEONG ZEE KIN DEPUTY COMMISSIONER FOR PERSONAL DATA PROTECTION 12 ",Directions,0705137f0dd7129af2528c049cc49cf5edda8502,"[""tags"",""decision"",""pdf-url"",""description"",""date"",""timestamp"",""url"",""title"",""nature"",""pdf-content""]" 2023-10-01T11:02:10+08:00,fbd32491db44d3d0c97aa12a99cefd61ec954264,50,50,1,1016,"A financial penalty of $37,500 was imposed on Stylez for failing to put in place reasonable security arrangements to protect personal data of its customers and cease retaining data when the purpose of collection no longer exists. As a result, the personal data of its customers was publicly exposed. A direction was also issued to Stylez to develop and implement internal data protection policies and practices to comply with the PDPA.","[""Protection"", ""Accountability"", ""Retention Limitation"", ""Financial Penalty"", ""Directions"", ""Accommodation and F&B"", ""Database""]",2021-10-14,https://www.pdpc.gov.sg/-/media/Files/PDPC/PDF-Files/Commissions-Decisions/Decision---Stylez-Pte-Ltd---04082021.pdf,"Protection, Accountability, Retention Limitation","Breach of the Protection, Accountability and Retention Limitation Obligations by Stylez",https://www.pdpc.gov.sg/all-commissions-decisions/2021/10/breach-of-the-protection-accountability-and-retention-limitation-obligations-by-stylez,2021-10-14,"PERSONAL DATA PROTECTION COMMISSION [2021] SGPDPC 8 Case No. DP-2001-B5645 In the matter of an investigation under section 50(1) of the Personal Data Protection Act 2012 And Stylez Pte Ltd … Organisation DECISION Stylez Pte. Ltd. [2021] SGPDPC 8 Lew Chuen Hong, Commissioner — Case No. DP-2001-B5645 4 August 2021 Introduction 1 On 25 December 2019, a local newspaper reported that data from a quotation and service comparison portal, iCompare.sg (“the Portal”), had been uploaded onto the Dark Web (the “Incident”)1 . The Personal Data Protection Commission (“the Commission”) commenced investigations into the Incident thereafter. Facts of the Case 2 The Portal was created and operated by Stylez Pte Ltd (“Organisation”) at the material time. In July 2016, the Organisation created a new database containing data from the Portal for the purposes of testing a new function for the Portal in a separate test environment (the “Testing Database”). The Testing Database was a text file comprising records of the Portal’s renovation and interior design clients from 2009 to 2016 and was hosted on a cloud server leased from a cloud storage service provider (“the Server”). 3 Investigations revealed that the data exposed in the Incident was accessed and exfiltrated from the Testing Database some time before December 2019. A total of 9,983 individuals’ personal data, comprising their name, email address, and phone number were exposed in the Incident. 4 The Portal’s production and backup databases were hosted on servers leased from a different cloud service provider and were unaffected in the Incident. 1 https://www.straitstimes.com/singapore/local-renovation-database-exposed-on-dark-web 2 Remedial actions 5 Following the Incident, the Organisation took the following remedial actions: a. The Testing Database and the account from which it was hosted were deleted; b. A malware scan was run on the Server, and all unnecessary files were removed; c. The operating system of the Server was updated and the root password was changed; d. A website security scanning tool was installed to conduct security scanning of the Portal; and e. The individuals affected in the Incident were notified. Findings and Basis for Determination Whether the Organisation contravened the Protection Obligation 6 Section 24 of the Personal Data Protection Act 2012 (“PDPA”) requires an organisation to protect personal data in its possession or under its control by making reasonable security arrangements to prevent unauthorised access, collection, use, disclosure, copying, modification, disposal or similar risks (the “Protection Obligation”). For the reasons set out below, the Organisation failed to implement reasonable security arrangements to protect the personal data in the Testing Database. 7 Firstly, the Testing Database was stored in a publicly accessible directory in the Server without any access controls. This resulted in the Testing Database being directly accessible from the Internet and crawled and indexed by search engines. This was a serious breach considering the volume of personal data contained in the Testing Database. 8 In the course of investigations, the Organisation characterised this as a failure to activate an anti-indexing function in the Server’s software, which could have prevented the 3 Testing Database’s URL from being indexed by search engines. This is incorrect. Even if the anti-indexing function had been activated, this would only have prevented the Server’s directory contents from being listed. The actual contents of any publicly listed directory on the Server could still have been crawled and indexed by search engines. Crucially, anti-indexing is not the same as access control and even if the Testing Database’s URL was not indexed, it could have been accessed directly without the need for authentication. This failure to appreciate the difference between anti-indexing and access control is a fundamental failing on the Organisation’s part. Proper authentication measures (e.g. password protection, access whitelisting) should have been implemented to control access to the Testing Database. 9 Secondly, privileged access to the Server (and in turn the Testing Database) was also not adequately secured. Though the password for the IT administrator’s account was strong (16 characters with upper and lower alphabets, numeric and special symbols), there was no limit imposed on the number of unsuccessful login attempts which could be made. This made the account vulnerable to brute-force attacks. The password to the IT administrator’s account was also stored in his email account in clear-text without the need for any two-factor authentication. This significantly weakened the protection accorded to the Server by strong login credentials. 10 Thirdly, the Testing Data was stored in the Server in an unencrypted format for more than two and a half years (i.e. from July 2016 to December 2019). While the Organisation claimed that the Testing Data was subsequently used for other business purposes, in general, production data (i.e. actual personal data) should not be held in less secure development environments for extended periods of time. This is discussed further below in relation to the Organisation’s breach of the Retention Limitation Obligation. 11 For the above reasons, it was determined that the Organisation breached the Protection Obligation in respect of the personal data in the Testing Database. 4 Whether the Organisation contravened the Accountability Obligation 12 Section 12(a) of the PDPA requires an organisation to develop and implement policies and practices that are necessary for the organisation to meet its obligations under the PDPA (the “Accountability Obligation”). 13 While the Organisation had developed an external data protection policy which communicated its purported data protection standards to customers and prospective customers, it failed to develop and implement any corresponding internal data protection policies to give effect to these externally communicated standards. 14 By way of illustration, the Organisation’s external data protection policy stated: “We have developed guidelines and implemented procedures to govern the destruction of personal data that are no longer required to fulfil the identified purposes.” 15 In fact, no such guidelines or procedures were implemented, and this made what was communicated to the Organisation’s customers and prospective customers effectively an empty promise. While the Organisation claimed that it had relied on verbal reminders to inform its staff on the importance of data protection, these reminders were undocumented, and in any event, inadequate. 16 An organisation will not be taken to have complied with the Accountability Obligation merely because it publishes and communicates a data protection policy to external parties. Any externally communicated data protection policy must be given the weight of the necessary internal policies and documented practices to guide an Organisation’s employees on how to comply with the PDPA in carrying out their work functions. 17 For this reason, the Organisation was determined to have breached the Accountability Obligation. 5 Whether the Organisation contravened the Retention Limitation Obligation 18 Section 25 of the PDPA requires an organisation to cease retaining data in a form that can identify the individual if the purpose of collection no longer exists, and if no business or legal reason exists for retention (the “Retention Limitation Obligation”). 19 In this case, the explicit purpose of creating the Testing Database was to test a particular new function for the Portal in a separate environment. That purpose no longer existed once the testing had been completed, and it was for the Organisation to justify why it continued to retain the Testing Database for any legal or business reasons. 20 The Organisation claimed that it had continued to retain the Testing Database for the purposes of business analysis, namely, to analyse (i) users’ requirements to improve the Organisation’s marketing strategy (i.e. specifications listed by users for their renovation or interior design jobs such as property type, room type, budget etc); and (ii) details on when users made enquiries via the Portal in order to optimise the timing of online advertising. The Organisation claimed that it could not have used other sources of data (such as their production or regular backup databases) for these purposes as there was a risk of causing inadvertent contamination of those databases if so used. 21 This justification was not accepted. Simply put, the business analysis described by the Organisation did not require retention of data that could identify individuals. Even if the Organisation wanted to retain the data in the Testing Database for these new business purposes, the data could have been aggregated or anonymised (i.e. with any personal identifiers removed) which would have taken the data outside the scope of regulated personal data, and allowed it to be used as unregulated anonymised data. 22 It was also doubted that the Organisation would have relied on historical data from as early as 2009 to conduct customer behaviour and preference studies when it would have been more commercially useful to conduct such studies based on more recent data. In any event, no 6 weight was placed on this factor in determining that the Organisation had failed to comply with the Retention Limitation Obligation in respect of the personal data in the Testing Database. 23 Had the Organisation carried out what it claimed that it would do in its external data protection policy (see [14] above), it may well have ceased retention of or at least anonymised the data in the Testing Database before the Incident. The Commissioner’s Directions 24 In determining whether to impose a financial penalty on the Organisation pursuant to section 48J(1) of the PDPA, and if so, the amount of such financial penalty, the factors listed at section 48J(6) of the PDPA were taken into account, as well as the following aggravating and mitigating factors: Aggravating Factors (a) The personal data of almost 10,000 individuals was publicly exposed in the Incident; (b) The Testing Database contained records that were 10 years old at the time of the Incident; (c) The Organisation misrepresented the standard of its internal data protection policies and practices to external parties; Mitigating Factors (d) The Organisation took prompt remedial actions after being notified of the Incident; and (e) The Organisation was cooperative during the investigations. 7 25 Having considered all the relevant factors of this case including representations made by the Organisation on 5 July 2021 after being notified of the Commissioner’s Preliminary Decision, the Commissioner hereby: (a) Requires the Organisation to pay a financial penalty of $37,500 in 12 monthly instalments by the due dates as set out in the notice accompanying this decision, failing which interest at the rate specified in the Rules of Court in respect of judgment debts shall accrue and be payable on the outstanding amount of such financial penalty until the financial penalty is paid in full; (b) Directs the Organisation to develop and implement internal data protection policies and practices to comply with the PDPA within 60 days of the relevant direction accompanying this decision, and to notify the Commission within 1 week of the completion of this direction. YEONG ZEE KIN DEPUTY COMMISSIONER FOR COMMISSIONER FOR PERSONAL DATA PROTECTION 8 ","Financial Penalty, Directions",573fcfa5db4c96ff1bb6711b02e1ab2d1d9cd20a,"[""tags"",""decision"",""pdf-url"",""description"",""date"",""timestamp"",""url"",""title"",""nature"",""pdf-content""]" 2023-10-01T11:02:10+08:00,fbd32491db44d3d0c97aa12a99cefd61ec954264,51,51,1,1016,Carousell was found not in breach of the PDPA in relation to incidents where threat actor accessed Carousell users' accounts due to credential stuffing.,"[""Not in Breach"", ""Others"", ""Password""]",2021-09-21,https://www.pdpc.gov.sg/-/media/Files/PDPC/PDF-Files/Commissions-Decisions/Decision---Carousell-Pte-Ltd---030821.pdf,,No Breach of the Protection Obligation by Carousell,https://www.pdpc.gov.sg/all-commissions-decisions/2021/09/no-breach-of-the-protection-obligation-by-carousell,2021-09-21,"PERSONAL DATA PROTECTION COMMISSION Case No. DP-2105-B8350 In the matter of an investigation under section 50(1) of the Personal Data Protection Act 2012 And Carousell Pte. Ltd. SUMMARY OF THE DECISION 1. On 14 May 2021, Carousell Pte. Ltd. (the “Organisation”) informed the Personal Data Protection Commission of an unauthorized access to their users’ accounts due to credential stuffing. 2. The Organisation was first alerted on 26 April 2021 when a user reported to the Organisation that his account had been hijacked and there were attempts to make unauthorised purchases. On 1 June 2021, the Organisation was alerted to another incident involving the same modus operandi where legitimate credentials were used to log in to users’ accounts and unauthorised purchases were made (collectively, the “Incident”). 3. The Organisation’s investigations indicated that the Incident was due to the threat actor(s) obtaining the login details and passwords of some of their users due to an exposure of the account details on another service provider’s platform. The threat actor(s) succeeded in certain cases where the user used the same login and password for their account with the Organisation and their compromised accounts with other provider’s platforms. After successfully logging into the account, the threat actor(s) was able to perform actions as an authorised user. The threat actor(s) would also have access to the data in an individual’s account and modify the account settings. 4. The Organisation’s investigations found that there was no known compromise or unauthorised access of information in other accounts that were stored in the same database. At the time of the Incident, the Organisation had in place security arrangements including, but not limited to, the following: a. Users are informed when there is a change to the password, email or phone number linked to their account, or when a new device is used to log in; b. Training of account takeover model to identify and investigate likely account takeovers; c. Card transactions that meet a certain fraud score are blocked or reviewed; d. One Time Password required to complete transactions for all card payments; e. Regular review of policies and regular testing and review of risk rules based on fraud trends, seasonality, regulation and all related indicators; f. Company-wide training and educational newsletters to increase staff awareness on security and data protection requirements; and g. Conduct annual penetration security assessment. 5. I am of the view that the Organisation had adopted reasonable standards for protecting personal data in their customer accounts on an objective review of the measures that were implemented at the time of the Incident. Further, the Organisation took prompt action to mitigate the effects of the breach by suspending the compromised users accounts and force password resets for affected users. Emails were sent to alert affected users of suspicious login in their accounts. DBS Paylah! Express Checkout was disabled for affected users whose accounts were suspected to have been compromised. 6. The Organisation also reviewed the Incident, and took remedial measures to enhance the robustness of their security measures, including but not limited to the following: a. Blocked suspicious IP addresses; b. Added rules into third party fraud detection tool to prevent account takeovers; c. Implemented a mandatory 2FA verification, via email, in the event there is a change detected in the user’s device ID across all platforms; and d. Efforts to educate users and raise awareness to fight against phishing attempts were enhanced. 7. Having found that at the time of the Incident, the Organisation had implemented reasonable security arrangements to protect the personal data under its control, I conclude that the Organisation did not breach its Protection Obligation under the Personal Data Protection Act. ",Not in Breach,da3c0f91c3b8e24ee0b6a4d9f85d596df8a36ab7,"[""tags"",""decision"",""pdf-url"",""description"",""date"",""timestamp"",""url"",""title"",""nature"",""pdf-content""]" 2023-10-01T11:02:10+08:00,fbd32491db44d3d0c97aa12a99cefd61ec954264,52,52,1,1016,"A financial penalty of $9,000 was imposed on Sendtech for failing to put in place reasonable security arrangements to protect personal data. This resulted in an unauthorised access of the personal data stored in their Amazon Web Services account.","[""Protection"", ""Financial Penalty"", ""Admin and Support Services"", ""Password""]",2021-09-21,https://www.pdpc.gov.sg/-/media/Files/PDPC/PDF-Files/Commissions-Decisions/Decision---Sendtech-Pte-Ltd---220721.pdf,Protection,Breach of the Protection Obligation by Sendtech,https://www.pdpc.gov.sg/all-commissions-decisions/2021/09/breach-of-the-protection-obligation-by-sendtech,2021-09-21,"PERSONAL DATA PROTECTION COMMISSION Case No. DP-2102-B7884 In the matter of an investigation under Section 50(1) of the Personal Data Protection Act 2012 And Sendtech Pte. Ltd. … Organisation SUMMARY OF THE DECISION 1. On 13 February 2021, Sendtech Pte. Ltd. (the “Organisation”) informed the Personal Data Protection Commission (the “Commission”) of a data breach incident. There was an unauthorized access to the Organisation’s Amazon Web Services (“AWS”) account via an access key (the “Incident”). 2. The Organisation became aware of the Incident on 10 February 2021 when its AWS account was shut down due to unusual account activity. The cause of Incident was a compromised AWS access key. This access key was created in 2015 when the Organisation was developing the backend of its server in its incipient stages. This AWS access key had not been rotated or changed since 2015. The Organisation suspected that the AWS could have been compromised through its former or current employees. First, all former developers had access to this key and some could still have the source code on their computers. Second, as most of the employees are working from home, it is possible that the AWS access key was compromised if the employees had accessed internet through a public WiFi connection. 3. With this compromised AWS access key, the attacker gained admin privileges, created another admin account and queried the buckets storing personal data. As a result, the personal data of 64,196 customers and 3,401 contractors and the contractors’ employees were accessed. There was no evidence of data exfiltration. For the customers, the personal data included the email address, contact number, home address and last four digits of the debit or credit card. For the contractors and their employees, the personal data included profile photo and copies of the NRIC or work permit (front and back). 4. The Organisation took the following remedial measures after the Incident: a. Rotated all access keys; b. Changed passwords for all servers; c. Enhanced its audit trail on AWS buckets to log all read and write operation at the object level; d. Checked and verified that its Github repositories was set to “Private”; e. Engaged cybersecurity consultants to carry out assessment of its security setup and advise on improvements to the security measures; and f. Developed new cybersecurity policies and processes which specifically include measures for credentials management. 5. In its representations to the Commission, the Organisation admitted to having breached the Protection Obligation under section 24 of the Personal Data Protection Act (the “PDPA”), and requested for the matter to be dealt with in accordance with the Commission’s Expedited Decision Procedure. 6. The Organisation admitted it did not have specific AWS policies for the assignment of roles to rotate credentials. There was also a lack of detailed steps to manage credentials access of outgoing staff. Hence, the credentials were not rotated or changed whenever there are staff movement. 7. In the circumstances, the Organisation is found to have breached section 24 of the PDPA. 8. On 23 June 2021, the Organisation was notified of the Commission’s intention to impose a financial penalty of $10,000 based on the Commission’s consideration of the factors listed under section 48J(6) of the PDPA, and the circumstances of this case, in particular (i) the Organisation’s upfront voluntary admission of liability which significantly reduced the time and resources required for investigations; and (ii) the prompt remedial actions undertaken by the Organisation. The Organisation was invited to make representations. Having considered the Organisation’s representations dated 25 June 2021 to reduce the financial penalty payable and to allow the Organisation to pay the financial penalty by way of an instalment plan the Deputy Commissioner hereby directs the Organisation to: a. Pay a financial penalty of $9,000 in 12 instalments by the due dates as set out below, failing which the full outstanding amount shall become due and payable immediately and interest at the rate specified in the Rules of Court in respect of judgment debts shall accrue and be payable on the outstanding amount of such financial penalty until the financial penalty is paid in full: i. 1st instalment of $750 on 1 September 2021; ii. 2nd instalment of $750 on 1 October 2021; iii. 3rd instalment of $750 on 1 November 2021; iv. 4th instalment of $750 on 1 December 2021; v. 5th instalment of $750 on 1 January 2022; vi. 6th instalment of $750 on 1 February 2022; vii. 7th instalment of $750 on 1 March 2022; viii. 8th instalment of $750 on 1 April 2022; 9. ix. 9th instalment of $750 on 1 May 2022; x. 10th instalment of $750 on 1 June 2022; xi. 11th instalment of $750 on 1 July 2022; and xii. 12th instalment of $750 on 1 August 2022. In view of the remedial actions taken by the Organisation, the Commission will not issue any directions under section 48I of the PDPA. ",Financial Penalty,cd74c714c427c34a4021513b29355c8019982bf8,"[""tags"",""decision"",""pdf-url"",""description"",""date"",""timestamp"",""url"",""title"",""nature"",""pdf-content""]" 2023-10-01T11:02:10+08:00,fbd32491db44d3d0c97aa12a99cefd61ec954264,53,53,1,1016,"A financial penalty of $13,500 was imposed on SAP Asia for failing to put in place reasonable security arrangements to protect personal data of its former employees. This resulted in an unauthorised disclosure of the personal data to unintended recipients.","[""Protection"", ""Financial Penalty"", ""Admin and Support Services"", ""Vendor""]",2021-09-21,https://www.pdpc.gov.sg/-/media/Files/PDPC/PDF-Files/Commissions-Decisions/Decision---SAP-Asia-Pte-Ltd---310721.pdf,Protection,Breach of the Protection Obligation by SAP Asia,https://www.pdpc.gov.sg/all-commissions-decisions/2021/09/breach-of-the-protection-obligation-by-sap-asia,2021-09-21,"PERSONAL DATA PROTECTION COMMISSION [2021] SGPDPC 6 Case No. DP-2004-B6180 In the matter of an investigation under section 50(1) of the Personal Data Protection Act 2012 And SAP Asia Pte. Ltd. … Organisation DECISION SAP Asia Pte. Ltd. [2021] SGPDPC 6 Lew Chuen Hong, Commissioner — Case No. DP-2004-B6180 30 July 2021 Introduction 1 On 1 April 2020, the Personal Data Protection Commission (“the Commission”) received a complaint that SAP Asia Pte. Ltd. (“the Organisation”) had disclosed the payroll information of some of its former employees to the wrong email recipients (“the Incident”). The Commission commenced investigations into the Incident thereafter. Facts of the Case 2 At the material time prior to the Incident, the Organisation had engaged an external vendor (“the Vendor”) to provide IT solutions for its human resources and payroll system (“the HR System”). The Organisation’s process of issuing payslips to its employees had been automated as part of the HR System. However, when payslips needed to be issued to individuals who had already left the employment of the Organisation (e.g. final payslips, reimbursements of expenses etc), this could not be done via the HR System. Such payslips needed to be separately generated by the Organisation’s human resources department and emailed to the former employees at their personal email addresses. The Organisation was keen to automate the process of issuing payslips to former employees as part of the HR System, and sometime around April 2019, requested the Vendor to develop a new programme within the HR System for this purpose (“the Programme”). 3 The Organisation had intended to use the Programme to generate and email multiple payslips to multiple former employees simultaneously in one execution of the Programme SAP Asia Pte. Ltd. [2021] SGPDPC 6 (“Multiple Payslip Issuance”). However, as will be discussed below, this intention was not properly communicated to the Vendor, and the Programme was designed on the incorrect understanding that only a single payslip would need to be issued to a single employee at a time (“Single Payslip Issuance”). 4 The Organisation executed the Programme for the first (and only) time on 31 March 2020 to generate and deliver payslips to 43 former employees at their personal email addresses. Believing the Programme to be capable of Multiple Payslip Issuance, the Organisation’s representative selected all 43 former employees to be issued payslips in one selection screen of the Programme and executed the process. As the Programme had not been designed to be able to properly execute Multiple Payslip Issuance, this execution of the Programme resulted in 29 out of the 43 former employees receiving their own payslip as well as the payslips of other employees. By way of illustration: (a) The 1st former employee in the selection received only their own payslip. (b) The 2nd former employee in the selection received their own payslip as well as the payslip of the 1st former employee. (c) The 3rd former employee in the selection received their own payslip as well as the payslips of the 1st and 2nd former employees. 5 13 of the 43 former employees had not provided the Organisation with valid email addresses and did not receive any emails with payslips. However, the payslips of these 13 former employees were still generated and disclosed to the 29 other former employees when the Programme was executed on 31 March 2020. 6 In all, the personal data of 43 former employees of the Organisation was improperly disclosed in the Incident. The disclosed personal data comprised each of the former employees’: 1 SAP Asia Pte. Ltd. [2021] SGPDPC 6 (a) Name; (b) NRIC or FIN number; (c) Employment number; (d) Bank account number; (e) Monthly basic salary; (f) Detailed breakdown of current payment; and (g) Year-To-Date earnings and deductions. Remedial actions 7 Following the Incident, as part of remedial actions, the Organisation: (a) Emailed all 43 former employees on 1 April 2020 informing them about the error and requesting each of them to delete the payslips which were not intended to be emailed to them; (b) Followed up with the former employees over phone to confirm deletion of the other payslips and received confirmation from 39 of the 43 former employees affected; (c) Disabled the Programme and reverted to manually generating and emailing payslips to former employees; and (d) Agreed on continuous process improvements with the Vendor with clear communicated requirements. 2 SAP Asia Pte. Ltd. [2021] SGPDPC 6 Findings and Basis for Determination Whether the Organisation contravened the Protection Obligation 8 Section 24 of the Personal Data Protection Act 2012 (“PDPA”) requires an organisation to protect personal data in its possession or under its control by making reasonable security arrangements to prevent unauthorised access, collection, use, disclosure, copying, modification, disposal or similar risks (the “Protection Obligation”). 9 In this case, the Organisation, a data controller, engaged the Vendor to develop a new feature for its IT systems which processed personal data in its possession (i.e. the Programme). The development of the Programme had obvious implications for the way in which the former employees’ personal data would be processed. However, in developing the Programme, the Vendor did not process personal data on behalf of the Organisation and was not the Organisation’s data intermediary in this regard. Accordingly, the Protection Obligation in respect of the former employees’ personal data was borne solely by the Organisation. 10 In the context of the Programme’s development, the Organisation’s responsibilities under the Protection Obligation included ensuring that: (a) The specifications provided to the Vendor accurately reflected the intended use of the IT feature being developed; and (b) Pre-launch testing of the new feature was accurately scoped to simulate the full range of intended use of the new feature. 11 For the reasons set out below, the Organisation failed both of these responsibilities. 3 SAP Asia Pte. Ltd. [2021] SGPDPC 6 Failure to adequately specify requirements for the Programme 12 It is a data controller’s responsibility to ensure that external vendors who are engaged to modify its IT systems know the scope of their work. As stated in (1) Smiling Orchid (S) Pte Ltd; (2) T2 Web Pte Ltd; (3) Cybersite Services Pte Ltd; (4) East Wind Solutions Pte Ltd [2016] SGPDPC 19 at [51]: “ Data controllers that (engage) outsourced service providers have to be clear about the nature and extent of services that the service provider is to provide. There must be a clear meeting of minds as to the services that the service provider has agreed to undertake, and this should be properly documented.” 13 This does not mean that all organisations will be expected to be able to give detailed technical instructions to their IT vendors. As clarified in MDIS Corporation Pte Ltd [2020] SGPDPC 11 at [14]: “While an organisation may not have — or need to have — the requisite level of technical expertise, a responsible organisation would have engaged competent service providers and made genuine attempts to give proper instructions. The Organisation is only expected to articulate its business requirements as owner of the system, which the service provider can translate into technical requirements. In addition, as the data controller, the Organisation is required to exercise reasonable oversight to ensure that its instructions are carried out.” [emphasis added] 14 In previous enforcement decisions, the Commissioner has held organisations in breach of the Protection Obligation for failing to properly communicate business requirements for design changes to IT features: 4 SAP Asia Pte. Ltd. (a) [2021] SGPDPC 6 In Singapore Cricket Association and another [2018] SGPDPC 19, the organisation engaged a vendor to redesign its website, including certain pages featuring profiles of its registered players. The organisation’s requirements were conveyed to the vendor piecemeal - in meetings, through phone calls, and over text messages. As a result, the vendor misunderstood the intended contents for the player profile pages and incorrectly disclosed around 100 players’ personal data including NRIC numbers and contact information as part of the redesigned website. (b) In The Central Depository (Pte) Limited & another [2019] SGPDPC 24, the organisation engaged a vendor to develop software to generate and issue notification letters to its customers. However, the organisation failed to provide the vendor with clear specifications and representative test data that covered the full range of data to be processed and the various processing scenarios. As such, the vendor incorrectly assumed that a particular dataset would always have 4 lines of data to extract for each letter, when in fact, that dataset could have also had 1, 2, or 3 lines of data. This resulted in a design error that caused the inadvertent disclosure of 1,358 customers’ personal data to the wrong recipients when the software was deployed. (c) In Horizon Fast Ferry Pte Ltd [2019] SGPDPC 27, a ferry operator engaged a vendor to redesign its booking website. There was no written contract between the parties, and all instructions and requirements for the redesign were conveyed verbally or over text messages. As a result, the vendor misunderstood the scope of the redesign and incorrectly imported an auto-population feature from one of the organisation’s internal systems to the redesigned website. This caused the booking form on the redesigned website to automatically populate all fields in the form whenever a passport number that matched an entry in the organisation’s passenger database was entered. As a result, the personal data of close to 300,000 of the organisation’s passengers was exposed to the risk of unauthorised access. 5 SAP Asia Pte. Ltd. 15 [2021] SGPDPC 6 In the present case, the Organisation failed to make clear to the Vendor that the Programme was intended to be used for Multiple Payslip Issuance. This resulted in the Vendor designing the Programme under the wrong impression that all that was required by the Organisation was Single Payslip Issuance. 16 The misunderstanding between the Organisation and Vendor was attributable to the Organisation’s instructions in relation to development of the Programme being brief and ambiguous. The Organisation’s instructions to the Vendor were contained in a short service request which read as follows: “HI Team, Can you please enhance the program (…) where by when i key in the employee id, (…) then A template of the email with the payslip is send to the selected employee? Thanks!” [emphasis added] 17 The request only referred to a payslip to be sent to a “selected employee” (i.e. in the singular) and not multiple employees (i.e. plural). 18 This reference to using the Programme for a single employee (as opposed to multiple employees) was repeated by the Organisation when later responding to clarifications sought by the Vendor as to why payslips needed to be sent to external email addresses: “HI (…), The sending of email to private address is necessary as we are require to provide payslip to ex employee when ever there is a payment. This is for employee who have left the organization. Thanks!” 6 SAP Asia Pte. Ltd. 19 [2021] SGPDPC 6 Apart from these communications, there was no other documentation of the Multiple Payslip Issuance requirement. If the Organisation intended to use the Programme to send payslips in a single instance to multiple former employees (i.e. Multiple Payslip Issuance) this should have been clearly communicated as a required specification for the Programme. The Organisation’s failure to properly communicate its business requirements to the Vendor resulted in the Programme being inadvertently designed in an insecure way. Failure to carry out adequate user acceptance testing 20 The Organisation’s failure to specify Multiple Payslip Issuance as a required functionality of the Programme was compounded by its failure to include any Multiple Payslip Issuance scenarios in its user-acceptance testing (“UAT”) for the Programme (i.e. testing carried out prior to deploying the Programme for use as part of the HR System). 21 Pre-launch testing is an important means of identifying data protection risks before new IT features are deployed in a live environment, and this has also been emphasised in the Commission’s recently published handbook, How to Guard Against Common Types of Data Breaches1: “Most organisations fail to recognise that proper testing can help them to identify defects in programming before a system is launched. Sufficient resources should be allocated for testing, and a comprehensive UAT should ensure good test coverage of scenarios including possible user journeys and exception handling. Organisations should also ensure that the planned UAT scenarios match real-world usage. This can be done through a comprehensive gathering of business requirements and identification of relevant usage scenarios by potential users. These should be driven by the business owner.” 1 https://www.pdpc.gov.sg/news-and-events/announcements/2021/05/handbook-on-how-to-guard-againstcommon-types-of-data-breaches-now-available 7 SAP Asia Pte. Ltd. [2021] SGPDPC 6 [emphasis added] 22 In previous enforcement decisions, organisations have been held in breach of the Protection Obligation for failing to properly scope pre-launch testing to simulate real-world use of new IT features: (a) In Option Gift Pte Ltd [2019] SGPDPC 10, the organisation developed a programme to send email confirmations to persons who had made gift redemption requests. The programme was intended to send a single email confirmation to each recipient. However, a coding error meant that while the first email was sent to the first recipient (as intended), the second email was sent to both the first and second recipient and so on (i.e. a similar type of error as in the Incident as described at [4] above). The organisation’s UAT was found to be inadequate as the programme had only been tested by sending confirmation emails to the same internal email address. There was no testing that simulated the intended use of the programme to send emails to multiple recipients. (b) In AIA Singapore Private Limited [2019] SGPDPC 20, the organisation employed an automated system to generate and send different types of letters to its customers. A fix had been deployed to correct an earlier programming error but ended up introducing a further error. When different types of letters were processed in one batch, the further error caused letters to be sent to the wrong recipients. The organisation’s testing prior to deploying the fix had only simulated scenarios in which one letter was generated at a time. However, this did not replicate the real-world use of the system as letters were ordinarily generated and dispatched in batches. (c) In Grabcar Pte Ltd [2020] SGPDPC 14, an update deployed for the organisation’s mobile application inadvertently exposed the personal data of some users to the risk of unauthorised access by other users. The error arose because the effect of the update on a particular caching mechanism had not been detected in testing. This 8 SAP Asia Pte. Ltd. [2021] SGPDPC 6 was partly because the organisation failed to test the update in scenarios where multiple users were accessing the application concurrently (which was a foreseeable real-world scenario). 23 Similar to the above precedents, in the present case, the Organisation’s representative only conducted 2 test scenarios as part of UAT, and both only involved Single Payslip Issuance. The failure to test Multiple Payslip Issuance as part of UAT meant that the testing was inadequate to simulate the Organisation’s intended use of the Programme, and the Programme’s incapability of handling Multiple Payslip Issuance was not picked up at the testing stage as it should have. 24 For the above reasons, the Organisation was determined to have breached the Protection Obligation in respect of the former employees’ personal data disclosed in the Incident. The Commissioner’s Directions 25 In determining whether to impose a financial penalty on the Organisation pursuant to section 48J(1) of the PDPA, and if so, the amount of such financial penalty, the factors listed at section 48J(6) of the PDPA were taken into account, as well as the following mitigating factors: Mitigating Factors (a) The Organisation took prompt remedial actions after being notified of the Incident; and (b) 26 The Organisation was cooperative during the investigations. Having considered all the relevant factors of this case, the Commissioner hereby requires the Organisation to pay a financial penalty of $13,500 within 30 days from the date of 9 SAP Asia Pte. Ltd. [2021] SGPDPC 6 the relevant notice accompanying this decision, failing which interest at the rate specified in the Rules of Court in respect of judgment debts shall accrue and be payable on the outstanding amount of such financial penalty until the financial penalty is paid in full. 27 No further directions are necessary on account of the remedial measures already taken by the Organisation. YEONG ZEE KIN DEPUTY COMMISSIONER FOR COMMISSIONER FOR PERSONAL DATA PROTECTION 10 ",Financial Penalty,b1202a44badfb2a4eadf02786aeafab69a9a4136,"[""tags"",""decision"",""pdf-url"",""description"",""date"",""timestamp"",""url"",""title"",""nature"",""pdf-content""]" 2023-10-01T11:02:10+08:00,fbd32491db44d3d0c97aa12a99cefd61ec954264,54,54,1,1016,"A financial penalty of $8,000 was imposed on Seriously Keto for failing to put in place reasonable security arrangements to protect the personal data stored in its server. This resulted in the data being subjected to a ransomware attack.","[""Protection"", ""Financial Penalty"", ""Accommodation and F&B"", ""Ransomware"", ""Vendor""]",2021-09-21,https://www.pdpc.gov.sg/-/media/Files/PDPC/PDF-Files/Commissions-Decisions/Decision---Seriously-Keto-Pte-Ltd---14072021.pdf,Protection,Breach of the Protection Obligation by Seriously Keto,https://www.pdpc.gov.sg/all-commissions-decisions/2021/09/breach-of-the-protection-obligation-by-seriously-keto,2021-09-21,"PERSONAL DATA PROTECTION COMMISSION Case No. DP-2006-B6449 In the matter of an investigation under section 50(1) of the Personal Data Protection Act 2012 And Seriously Keto Pte. Ltd. SUMMARY OF THE DECISION 1. On 16 June 2020, Seriously Keto Pte Ltd (the “Organisation”) notified the Personal Data Protection Commission (the “Commission”) of a ransomware infection that occurred on or about 15 June 2020 (the “Incident”). The affected personal data comprised approximately 3,073 individuals’ names, addresses, email addresses and telephone numbers (“the Affected Personal Data”). 2. The Organisation requested that the Commission investigate the Incident under its Expedited Decision Procedure. In this regard, the Organisation voluntarily provided and unequivocally admitted to the facts set out in this decision. It also admitted that it was in breach of the Protection Obligation under section 24 of the Personal Data Protection Act (the “PDPA”). 3. Investigations revealed the presence of an unprotected file in the Organisation’s network infrastructure which contained unencrypted login credentials to access the server containing the Affected Personal Data. The unprotected file could be located by infrastructure scanning, and this provided a channel for unauthorised access to the server. Server logs retrieved by the Organisation after the Incident indicated that there had been unauthorised access to the file. 4. The Organisation admitted that it had failed to conduct any periodic security reviews prior to the Incident which could have revealed the existence of the unprotected file within its network infrastructure. 5. The Organisation had engaged a vendor to develop its e-commerce and membership website and claimed to have relied on the vendor to make the necessary security arrangements to protect the Affected Personal Data. However, in this case, there were no clear business requirements (e.g. contractual stipulations) specifying that the Organisation was relying on the vendor to recommend and/or implement security arrangements to protect personal data hosted in the e-commerce and membership website that the vendor was engaged to develop. Protection of personal data in the possession or under the control lies primarily with the Organisation, although it may contract the operations to a vendor who is more knowledgeable and with expertise. To do so, the Organisation has to be clear about the scope of outsourcing and the vendor has to also agree to do so. In the absence of clear outsourcing, the responsibility to implement reasonable security arrangements to protect the Affected Personal Data remained squarely with the Organisation. 6. Overall, the Organisation admitted that it had failed to give due attention to personal data protection prior to the Incident and had neglected to implement reasonable security arrangements to protect the Affected Personal Data. 7. In the above circumstances, the Deputy Commissioner for Personal Data Protection finds that the Organisation negligently contravened the Protection Obligation under section 24 of the PDPA. 8. Following the Incident, the Organisation underwent a full security audit and remedied vulnerabilities identified. The Organisation also set up a new website with a more robust internal security infrastructure, implemented a mandatory password change for all users of its new website, and activated a firewall to safeguard access to the new website. It also engaged a cybersecurity vendor to develop further measures and policies to strengthen its internal IT infrastructure. Additionally, the Organisation committed to engaging consultants to improve its data protection policies and outsource data protection functions. 9. The Organisation cooperated with the Commission’s investigation, admitted to its breach of the Protection Obligation, and took prompt remedial action. There was no evidence of exfiltration of the Affected Personal Data, and the Organisation was able to restore the Affected Personal Data from a backup and did not lose any data as a result of the Incident. The practice of having regular and separately located data backup(s) is to be encouraged to prevent organisations from losing data to ransomware. 10. Having considered the above circumstances and the factors listed at section 48J(6) of the PDPA, the Deputy Commissioner for Personal Data Protection requires the Organisation to pay a financial penalty of $8,000 within 30 days from the date of the notice accompanying this decision, failing which interest at the rate specified in the Rules of Court in respect of judgment debts shall accrue and be payable on the outstanding amount of such financial penalty until the financial penalty is paid in full. 11. In view of the remedial actions taken by the Organisation, no other directions are necessary. ",Financial Penalty,f96a9b453e14796f77b805ed107e916524839f6e,"[""tags"",""decision"",""pdf-url"",""description"",""date"",""timestamp"",""url"",""title"",""nature"",""pdf-content""]" 2023-10-01T11:02:10+08:00,fbd32491db44d3d0c97aa12a99cefd61ec954264,55,55,1,1016,"A warning was issued to Specialized Asia Pacific for failing to put in place reasonable security arrangements to protect the personal data of 2,445 application users.","[""Protection"", ""Warning"", ""Others"", ""Mobile application""]",2021-09-21,https://www.pdpc.gov.sg/-/media/Files/PDPC/PDF-Files/Commissions-Decisions/Decision---Specialized-Asia-Pacific-Pte-Ltd---300721.pdf,Protection,Breach of the Protection Obligation by Specialized Asia Pacific,https://www.pdpc.gov.sg/all-commissions-decisions/2021/09/breach-of-the-protection-obligation-by-specialized-asia-pacific,2021-09-21,"PERSONAL DATA PROTECTION COMMISSION Case No. DP-2101-B7826 In the matter of an investigation under Section 50(1) of the Personal Data Protection Act 2012 And Specialized Asia Pacific Pte Ltd … Organisation SUMMARY OF THE DECISION 1. On 29 January 2021, Specialized Asia Pacific Pte Ltd. (the “Organisation”) informed the Personal Data Protection Commission of a data security incident involving the Specialized Cadence application (the “Application”) that it developed, operated and maintained. 2. The Organisation’s developing staff did not realize that the online development tool, which was used to develop the Application, had a default privacy setting that made all data created by users or developers “visible”, even though this had been stated in the tool’s privacy rules. This default setting allowed the Application’s network traffic to be intercepted and accessed using third-party security testing software that can be acquired online. A member of the public had therefore been able to intercept and access the personal data of the Application’s users by using a free version of such software (the “Incident”). However, the risk of unauthorised access had been limited to parties who knew how to use such security testing software to obtain access. This factored in the enforcement outcome below (see paragraph 6 below). 3. The undetected default privacy setting of “visible” put the personal data of 2,445 individuals at risk of unauthorised access. The data affected included names, addresses, dates of birth, telephone numbers, email addresses and gender. 4. Remediation by the Organisation encompassed turning off all access and use of the Application by all external parties, including users, and changing the privacy setting from “visible” to “hidden”. The Organisation also engaged a third-party IT security firm to test and address any security and privacy issues relating to the Application, commenced discussions with its IT application designers and employees involved to adopt ‘privacyby-design’ in future applications development. 5. The Protection Obligation in section 24 of the Personal Data Protection Act 2012 requires that organisations understand the privacy policies and security features of all online tools or software they choose to employ. This was established in published cases such as Re GMM Technoworld Pte. Ltd. [2016] SGDPDPC 18. Organisations employing online tools or other online software must set or reconfigure privacy policies and security features to protect the personal data of application or website users. It would not be a discharge of the Protection Obligation for an organisation to simply adopt, vis-à-vis users, the same default privacy policies of online tools or software that do not protect the personal data of users. 6. The Deputy Commissioner for Personal Data Protection therefore found the Organisation in breach of the Protection Obligation under Section 24 of the Personal Data Protection Act 2012. Upon consideration of the facts, including the limited exposure of the affected data to those who knew how to use the above-mentioned third party software to access such information via the default privacy setting, and the Organisation’s commitment to improve its processes, a Warning was issued to the Organisation. ",Warning,bb6b30899dc237cbbb5ca65a53c42a6e8fc69444,"[""tags"",""decision"",""pdf-url"",""description"",""date"",""timestamp"",""url"",""title"",""nature"",""pdf-content""]" 2023-10-01T11:02:10+08:00,fbd32491db44d3d0c97aa12a99cefd61ec954264,56,56,1,1016,Directions were issued to NUInternational Singapore and Newcastle Research and Innovation Institute for breach of the PDPA in relation to the transfer of Singapore-based individuals’ personal data to their ultimate parent company in the United Kingdom and related company in Malaysia.,"[""Transfer Limitation"", ""Directions"", ""Education"", ""Ransomware"", ""Consent""]",2021-09-21,https://www.pdpc.gov.sg/-/media/Files/PDPC/PDF-Files/Commissions-Decisions/Decision---NUI-and-NewRIIS--23062021.pdf,Transfer Limitation,Breach of the Transfer Limitation Obligation by NUInternational Singapore and Newcastle Research and Innovation Institute,https://www.pdpc.gov.sg/all-commissions-decisions/2021/09/breach-of-the-transfer-limitation-obligation-by-nuinternational-singapore-and-newcastle-research-and-innovation-institute,2021-09-21,"PERSONAL DATA PROTECTION COMMISSION [2021] SGPDPC 5 Case No. DP-2009-B7011 In the matter of an investigation under section 50(1) of the Personal Data Protection Act 2012 And (1) NUInternational Singapore Pte Ltd (2) Newcastle Research and Innovation Institute Pte Ltd … Organisations DECISION (1) NUInternational Singapore Pte Ltd; (2) Newcastle Research and Innovation Institute Pte Ltd [2021] SGPDPC 5 Yeong Zee Kin, Deputy Commissioner — Case No. DP-2009-B7011 23 June 2021 Introduction 1 On 17 September 2020 and 13 November 2020, the Personal Data Protection Commission (the “Commission”) was notified of a ransomware attack relating to Newcastle Research and Innovation Institute Pte Ltd and NUInternational Singapore Pte Ltd (collectively known as the “Organisations”) in Singapore (the “Incident”). Facts of the case 2 The ransomware infected, on or around 30 August 2020, (a) a database in the United Kingdom, managed by the ultimate parent company of the Organisations (containing 1,083 records of Singapore-based individuals); and (b) a database in Malaysia, hosted by a related company of the Organisations (containing 194 records of Singapore-based individuals). These records containing personal data of the Singapore-based individuals were previously transferred from the Organisations to the ultimate parent company in the United Kingdom and the related company in Malaysia respectively. The Singapore-based individuals were a mix of staff members, undergraduates and/or post-graduate students of the Organisations. Their 2 personal data (comprising names and user account identifications) were exfiltrated by the threat actor. Findings and Basis for Determination 3 Section 26(1) of the PDPA stipulates that an organisation shall not transfer any personal data to a country or territory outside Singapore except in accordance with the requirements prescribed under the PDPA to ensure that organisations provide a standard of protection to personal data so transferred that is comparable to the protection under the PDPA (the “Transfer Limitation Obligation”). The requirements mentioned in section 26(1) were set out in Regulations 9 and 10 of the Personal Data Protection Regulations 2014 (which were in force at the time) (the “Transfer Regulations 2014”). The Transfer Regulations 2014 was recently amended (“the Transfer Regulations 2021”). The ensuing analysis and application of the Transfer Regulations 2014 is equally relevant for the Transfer Regulations 2021, which is in pari materia but for some re-numbering of the regulations. 4 The Transfer Regulations 2014 provides for a range of transfer mechanisms to ensure compliance with Section 26(1) of the PDPA, e.g. through legally enforceable obligations under any law, contracts, binding corporate rules or any other legally binding instruments. Within a group of companies, reliance on intra-group agreements and binding corporate rules is common for cross-border data transfers. They provide a flexible system for centralisation of corporate functions and services. The commercial decision would be driven by where these functions are best located, and intra-group agreements and binding corporate rules allow the group to establish a bespoke internal governance system to ensure that personal data is well managed 3 across the group. The Transfer Regulations 2014 (and 2021) support the adoption of intragroup agreements and binding corporate rules in the following manner. 5 Pursuant to Regulation 9(1)(b), the Organisations could have met the Transfer Limitation Obligation by taking appropriate steps to ensure that the recipients of the transferred personal data in United Kingdom and Malaysia were bound by legally enforceable obligations (in accordance with Regulation 10(1) of the Transfer Regulations 2014) to provide to the transferred personal data a standard of protection that is at least comparable to that under the PDPA. Regulation 9(1)(b) is now Regulation 10(1) in the Transfer Regulations 2021. Regulation 10(1) of the Transfer Regulations 2014 specifies that such legally enforceable obligations includes any law, a contract that complies with the conditions in Regulation 10(2), or binding corporate rules that meets the conditions set out in Regulation 10(3). These same regulations are now in Regulation 11 in the Transfer Regulations 2021. These regulations support the use of intra-group agreements1 and binding corporate rules2. 6 Investigations revealed that the Organisations did not put in place intra-group agreements, binding corporate rules or any other legally binding instrument to ensure that a standard of protection comparable to the PDPA is provided to personal data transferred within the group as required by Regulation 10(1). 7 In its responses to the Commission, the Organisations put forward the argument that they had met the Transfer Limitation Obligation under the PDPA by virtue of the fact that the laws of the United Kingdom applied to the receiving organisations within their group. I do not exclude the possibility that the data protection system that governs the receiving organisation 1 2 See Re Everlast Projects & Others [2020] SGPDPC 20 at [13]. See Re Singapore Technologies Engineering Limited [2020] SGPDPC 21. 4 may, on a proper analysis, provide comparable protection. However, based on the responses made by the Organisations to the Commission, I am not satisfied that the transferring organisation conducted this analysis and concluded that there would be comparable protection before the transfer. After the fact justification will not be accepted. 8 Of the 1,083 Singapore-based individuals whose personal data had been transferred to the ultimate parent company in the United Kingdom, the Organisations mentioned that 44 of these individuals, who were employees, had consented to the transfer of their personal data out of Singapore in their employment contracts. Regulation 9(3)(a) of the Transfer Regulations 2014 did provide for the Transfer Limitation Obligation to be met by obtaining the consent of individuals for the transfer of their data. However, to meet the consent requirement under Regulation 9(3)(a) of the Transfer Regulations 2014, Regulation 9(4) requires the Organisations to provide to the individuals a summary in writing of the extent to which their personal data, when transferred to a foreign country or territory, would be protected to a standard comparable to the PDPA. These requirements are now encapsulated in Regulations 10(2)(a) and 10(3) of the Transfer Regulations 2021. The procedural safeguards established by Regulation 9(3) of the Transfer Regulations 2014 makes the use of consent somewhat more cumbersome, as there is a need for consent to be refreshed whenever reorganisation of the group’s internal function leads to a relocation of that function in a different jurisdiction. This also does not enable the Organisations to benefit from the employment management exception to the requirement for consent. Be that as it may, this option is available for organisations that choose to rely on it. However on the evidence, this summary in writing was not provided by the Organisations to the 44 Singapore employees. 5 The Deputy Commissioner’s Directions 9 In view of the foregoing, I therefore find that the Organisations have failed to discharge their Transfer Limitation Obligation under section 26 of the PDPA. The Organisations are directed to do the following within 30 days from the date of this Decision: (a) put in place intra-group agreements or binding corporate rules for compliance with section 26 of the PDPA in relation to any personal data transferred out of Singapore3; (b) if relying on consent, review and make necessary changes to its consent and notification processes for compliance with section 26 of the PDPA and Regulation 10(3) of the Personal Data Protection Regulations 2021 in relation to any personal data transferred out of Singapore; and (c) inform the Commission of the completion of the above within 7 days of implementation. YEONG ZEE KIN DEPUTY COMMISSIONER FOR PERSONAL DATA PROTECTION 3 Refer to Regulation 11 of Personal Data Protection Regulations 2021, which is applicable at the present time. 6 ",Directions,3b598c8a7be71e58fadf5f81e6bf2476ad13c791,"[""tags"",""decision"",""pdf-url"",""description"",""date"",""timestamp"",""url"",""title"",""nature"",""pdf-content""]" 2023-10-01T11:02:10+08:00,fbd32491db44d3d0c97aa12a99cefd61ec954264,57,57,1,1016,Singapore Telecommunications Limited was found not in breach of the PDPA in relation to an incident which occurred on or about 13 July 2020 where a threat actor accessed the accounts belonging to 17 subscribers.,"[""Not in Breach"", ""Information and Communications"", ""Phishing""]",2021-08-12,https://www.pdpc.gov.sg/-/media/Files/PDPC/PDF-Files/Commissions-Decisions/Decision---Singapore-Telecommunications-Limited---21062021.pdf,,No Breach of the Protection Obligation by Singapore Telecommunications Limited,https://www.pdpc.gov.sg/all-commissions-decisions/2021/08/no-breach-of-the-protection-obligation-by-singapore-telecommunications-limited,2021-08-12,"PERSONAL DATA PROTECTION COMMISSION Case No. DP-2007-B6607 In the matter of an investigation under section 50(1) of the Personal Data Protection Act 2012 And Singapore Telecommunications Limited SUMMARY OF THE DECISION 1. On 15 July 2020, Singapore Telecommunications Limited (the “Organisation”) informed the Personal Data Protection Commission of an incident which had occurred on or about 13 July 2020 (the “Incident”). In the Incident, a threat actor accessed the accounts of 17 of the Organisation’s telecommunications service subscribers to request for issuance of new SIM cards, forwarding of voice calls and/or cessation of mobile services 1 . Once these were issued, the affected subscribers were unable to access to their own accounts. 2. The Organisation investigations indicated that the Incident was due to threat actor(s) who gained access to its IT systems through coordinated social engineering tactics targeted at staff. The threat actor(s)’ aim was to use compromised staff accounts to gain control of subscriber accounts of the affected individuals to perform unauthorised activities. 3. The Organisation also made reports to IMDA under the Telecoms Act and the Singapore Police Force (“SPF”). 4. The Organisation’s investigations found no evidence that the integrity of its affected IT systems had been compromised or that any data had been exfiltrated from the systems at the time of the Incident, the Organisation had in place reasonable security arrangements that included the following: a. Password requirements in security policies, standards and guidelines were aligned to industry best practices; 1 Singtel stated that the threat actor could have also accessed the records of an additional 15 subscribers. b. Systems and network enhancements were continually implemented to improve the security of applications and IT infrastructure; c. Comprehensive and annual mandatory training was conducted for all staff in relation to the requirements under the PDPA; and d. Reasonable security measures were in place for the work environment of all staffs based locally and overseas. 5. The Organisation took prompt action to mitigate the effects of the breach by suspending the compromised staff accounts and by password resets. Apart from exclusion from their account for a limited duration, no other loss or damage to any individual was reported from the Incident. Remedial action to prevent recurrence will remain confidential for security reasons. 6. The Deputy Commissioner for Personal Data Protection found that the Organisation had met its Protection Obligation in the circumstances. No enforcement action therefore needs to be taken in relation to the Incident. ",Not in Breach,01a5079b89086159131ed4e343c0e882d01a1e85,"[""tags"",""decision"",""pdf-url"",""description"",""date"",""timestamp"",""url"",""title"",""nature"",""pdf-content""]" 2023-10-01T11:02:10+08:00,fbd32491db44d3d0c97aa12a99cefd61ec954264,58,58,1,1016,"A financial penalty of $7,000 was imposed on Larsen & Toubro Infotech for failing to put in place reasonable security arrangements to prevent the unauthorised disclosure of personal data of job applicants, and for disclosing the personal data of job applicants without their consent.","[""Protection"", ""Consent"", ""Financial Penalty"", ""Information and Communications"", ""Protection"", ""Consent"", ""Sample forms"", ""Email"", ""Recruitment""]",2021-06-10,https://www.pdpc.gov.sg/-/media/Files/PDPC/PDF-Files/Commissions-Decisions/Decision--Larsen--Toubro-Infotech-Limited-Singapore-Branch-06052021.pdf,"Protection, Consent",Breach of the Protection and Consent Obligation by Larsen & Toubro Infotech,https://www.pdpc.gov.sg/all-commissions-decisions/2021/06/breach-of-the-protection-and-consent-obligation-by-larsen-toubro-infotech,2021-06-10,"PERSONAL DATA PROTECTION COMMISSION Case No. DP-2011-B7464 In the matter of an investigation under section 50(1) of the Personal Data Protection Act 2012 And Larsen & Toubro Infotech Limited, Singapore Branch SUMMARY OF THE DECISION 1. On 29 November 2020, the Personal Data Protection Commission (the “Commission”) received a complaint against Larsen & Toubro Infotech Limited, Singapore Branch (“LTI”) from an LTI job applicant. 2. On 25 November 2020, an LTI employee had emailed the complainant a set of sample forms which contained the personal data of a past job applicant. The LTI employee had sent the complainant those sample forms to assist him in filling up his own forms correctly. 3. Subsequently, on 3 December 2020, another LTI employee sent an email reminder to the complainant and 53 other job applicants to complete their application process. The email contained all of the job applicants’ respective names, with their email addresses placed in the “To” field and thus visible to all recipients. 4. Once notified of the complaint by the Commission, LTI undertook a review of its employees’ emails for the period from 2016 to 2020, and uncovered 73 other instances where past job applicants’ personal data had been disclosed to other job applicants. 5. In total, 13 past job applicants’ forms were disclosed by 10 of LTI’s employees to 74 other job applicants. The personal data disclosed in the forms comprised: a. Name; b. Signature; c. Email address; d. National Identification/ passport numbers; e. Date of Birth; f. Address; g. Contact number; h. Medical health status; i. Employment history; j. Salary information; and k. Criminal records disclosure. 6. The Deputy Commissioner for Personal Data Protection finds that LTI negligently contravened the Protection Obligation under section 24 of the Personal Data Protection Act 2012 by failing to provide adequate instructions to its employees dealing with recruitment matters on how to handle personal data. LTI also negligently contravened the Consent Obligation under section 13 of the Personal Data Protection Act 2012, by disclosing the names and email addresses of all job applicants in its email sent to the 54 job applicants on 3 December 2020, including the complainant. 7. While LTI claimed to have a general Corporate Privacy Policy and an Employee Privacy Notice which applied to all employees, the purpose of these documents was to provide notice to individuals and employees on how LTI used, processed, and protected personal data. Guidance to employees on how they should handle personal data in the course of work could only be found in LTI’s “Data Privacy Awareness” training materials. LTI had no targeted policies or standard operating procedures specifically for the employees handling recruitment matters, despite the type and volume of personal data handled by such employees. The fact that as many as 10 of LTI’s employees had engaged in the same conduct over a 4 year period, reinforced the finding that the existing instructions were inadequate. 8. LTI indicated that it would make all its employees aware of this incident, and that it would implement a new set of procedures for email communications to external job applicants. LTI notified all affected job applicants of the wrongful disclosure of their personal data to other job applicants, and informed the job applicants to delete the emails they had received containing the affected job applicants’ forms. Refresher training was also conducted for the employees who had sent the emails. 9. After considering the circumstances of the case and the factors listed at section 48J(6) of the Personal Data Protection Act 2012, including LTI’s cooperation with investigations, its proactive review to identify additional historical breaches, and its prompt remedial actions, the Deputy Commissioner for Personal Data Protection requires that LTI pay a financial penalty of $7,000 for the breach. 10. LTI must make payment of the financial penalty within 30 days from the date of this decision, failing which interest at the rate specified in the Rules of Court in respect of judgment debts shall accrue and be payable on the outstanding amount of the financial penalty until it is paid in full. 11. No further directions are required as LTI had taken actions to address the gaps in its security arrangements. ",Financial Penalty,bd9f440070a5521214d61291f17b40de724a111a,"[""tags"",""decision"",""pdf-url"",""description"",""date"",""timestamp"",""url"",""title"",""nature"",""pdf-content""]" 2023-10-01T11:02:10+08:00,fbd32491db44d3d0c97aa12a99cefd61ec954264,59,59,1,1016,"A financial penalty of $25,000 was imposed on Webcada for breaches of the PDPA. First, the organisation failed to put in place reasonable measures to protect personal data on its database servers. Second, it did not have written policies and practices necessary to ensure its compliance with the PDPA.","[""Protection"", ""Accountability"", ""Financial Penalty"", ""Information and Communications"", ""Ransomware"", ""IPMI"", ""Database servers"", ""No Written Policy""]",2021-06-10,https://www.pdpc.gov.sg/-/media/Files/PDPC/PDF-Files/Commissions-Decisions/Decision---Webcada-Pte-Ltd-06052021.pdf,"Protection, Accountability",Breach of the Protection and Accountability Obligation by Webcada,https://www.pdpc.gov.sg/all-commissions-decisions/2021/06/breach-of-the-protection-and-accountability-obligation-by-webcada,2021-06-10,"PERSONAL DATA PROTECTION COMMISSION Case No. DP-2009-B6931 In the matter of an investigation under section 50(1) of the Personal Data Protection Act 2012 And Webcada Pte Ltd SUMMARY OF THE DECISION 1. On 4 September 2020, Webcada Pte Ltd (the “Organisation”) notified the Personal Data Protection Commission (the “Commission”) that three of its database servers had been subjected to a ransomware attack on 29 August 2020 (the “Incident”). 2. The personal data of 522,722 individuals were affected in the Incident. The datasets affected comprised of the individuals’ names, phone numbers, dates of birth, addresses and order histories. 3. Following the Incident, the Organisation engaged an independent third-party consultant to investigate, review and assist in the implementation of additional data protection measures. 4. Investigations revealed that the ransomware had been uploaded onto the affected servers via the Intelligent Platform Management Interface (""IPMI""). The IPMI is a set of computer interface specifications used for remote monitoring and management of servers. There was no evidence of data exfiltration, and all affected data was restored from available back-ups. 5. The Organisation took the following remedial measures after the Incident: (a) IPMI was permanently disabled for all servers; (b) The public IP address of all servers was removed and all remote management access to the servers was configured to allow only trusted IP addresses; (c) End-point protection software with threat hunting capabilities was installed on all servers and computers within the Organisation; and (d) A written data protection policy was developed and implemented to comply with the provisions of the Personal Data Protection Act 2012 (the ""PDPA""). 6. In its representations to the PDPC, the Organisation admitted to having breached the Accountability Obligation under section 12 and the Protection Obligation under section 24 of the PDPA, and requested for the matter to be dealt with in accordance with the PDPC’s Expedited Decision Procedure. Section 12 of the PDPA 7. First, the Organisation admitted it did not have a written data protection policy prior to the Incident. In this regard, it is important to reiterate that an organisation must document its data protection policies and practices in writing as they serve to increase awareness and ensure accountability of the organisation's obligations under the PDPA. This requirement has been emphasized multiple times in previous decisions1. Section 24 of the PDPA 8. Second, the Organisation admitted that it did not configure its IPMI access settings correctly prior to the Incident. It enabled access to the IPMI from the public Internet when this was not necessary. Furthermore, in the monthly vulnerability scans carried out by the Organisation, it had omitted to scan the IPMI. Hence, it was not able to detect vulnerabilities in its IPMI, which were exploited to gain access to and upload the ransomware on the servers. 9. In the circumstances, the Organisation is found to have breached sections 12 and 24 of the PDPA. 10. After considering the factors listed at section 48J(6) of the PDPA and the circumstances of this case, including (i) the Organisation's upfront voluntary admission of liability which significantly reduced the time and resources required for investigations; and (ii) the Organisation's prompt remedial actions, the Organisation is given notice to pay a financial penalty of $25,000. 1 See Re Aviva Ltd [2017] SGPDC 14 at [32]; Re Singapore Taekwondo Federation [2018] SGPDC 17 at [39] to [42]; Re AgcDesign Pte Ltd [2019] SGPDC 23 at [4] to [5]; Re (1)Everlast Projects Pte Ltd (2)Everlast Industries (S) Pte Ltd (3) ELG Specialist Pte Ltd [2020] SGPDC 20 at [8] to [9] 11. The Organisation must make payment of the financial penalty within 30 days from the date of the notice accompanying this decision, failing which interest at the rate specified in the Rules of Court in respect of judgment debts shall accrue and be payable on the outstanding amount of such financial penalty until the financial penalty is paid in full. 12. In view of the remedial actions taken by the Organisation, the Commission will not issue any directions under section 48I of the PDPA. ",Financial Penalty,a8330d4666d7631b3e448330fd698843754474f4,"[""tags"",""decision"",""pdf-url"",""description"",""date"",""timestamp"",""url"",""title"",""nature"",""pdf-content""]" 2023-10-01T11:02:10+08:00,fbd32491db44d3d0c97aa12a99cefd61ec954264,60,60,1,1016,"A financial penalty of $35,000 was imposed on HMI Institute for failing to put in place reasonable security arrangements to protect personal data stored in its server. This resulted in the data being subjected to a ransomware attack.","[""Protection"", ""Financial Penalty"", ""Education"", ""Ransomware"", ""Third Party Vendor"", ""Scope of Duties"", ""Open RDP Port"", ""Remote Desktop Protocol""]",2021-06-10,https://www.pdpc.gov.sg/-/media/Files/PDPC/PDF-Files/Commissions-Decisions/Decision---HMI-Institute-of-Health-Sciences---20052021.pdf,Protection,Breach of the Protection Obligation by HMI Institute of Health Sciences,https://www.pdpc.gov.sg/all-commissions-decisions/2021/06/breach-of-the-protection-obligation-by-hmi-institute-of-health-sciences,2021-06-10,"PERSONAL DATA PROTECTION COMMISSION [2021] SGPDPC 4 Cases No DP-1912-B5434 / DP-1912-B5564 / DP-1912-B5558 In the matter of an investigation under section 50(1) of the Personal Data Protection Act 2012 And HMI Institute of Health Sciences Pte. Ltd. … Organisation DECISION HMI Institute of Health Sciences Pte. Ltd. [2021] SGPDPC 4 Lew Chuen Hong, Commissioner — Cases No. DP-1912-B5434 / DP-1912-B5564 / DP-1912-B5558 20 May 2021 Introduction 1 On 4 December 2019, a file server (the “Server”) belonging to HMI Institute of Health Sciences Pte. Ltd. (the “Organisation”) was affected by a ransomware attack. The ransomware encrypted and denied access to various files on the Server, including files containing personal data of the Organisation’s staff and trainees (the “Incident”). 2 On 7 December 2019, the Organisation informed the Personal Data Protection Commission (“Commission”) of the Incident. The Commission subsequently received two separate complaints about the Incident. Background 3 The Organisation is a dedicated private provider of healthcare training to individuals (“Participants”) in Singapore. In the course of carrying out its business activities, the Organisation collects personal data from, among others, (i) its employees, including temporary and contract staff such as associate trainers, (“Employees”) for the purposes of managing or terminating such employment relationships, and (ii) the Participants, for the purposes of registration and the administration of their enrolment in the Organisation’s training courses. 4 The Server affected by ransomware was set up in 2014 and was located in Singapore. It was owned by the Organisation but maintained by the Organisation’s appointed IT solution service provider (the “Vendor”). The Server stored personal data in Microsoft Word or Excel files, most but not all of which were password-protected. 5 The Server was protected by a firewall that blocked all connections to the Server, except for those through port 3389, a standard port which was used for the Remote Desktop Protocol (“RDP Port”). The RDP Port was used by the Vendor for 1 remote management and/or troubleshooting purposes. According to the Organisation, the RDP Port was kept open from sometime in 2014 up to the date of the Incident on 4 December 2019 (i.e. for more than four (4) years) to allow the Vendor quick and easy access. The significance of the RDP Port being kept open will be elaborated on below. 6 The Server only had one administrator account which was shared by the Organisation’s IT administrator and at least three other employees of the Vendor. By use of this administrator account, the Vendor could access the Server remotely through the RDP Port and view, change, or delete all the data in the Server. 7 On 4 December 2019, an employee of the Organisation was unable to access files on the Server containing the personal data of some Participants. An initial diagnostic conducted by the Vendor revealed that the Server had been affected by ransomware. File extensions of the files on the Server had been changed and a ransom note was found on the Server. 8 On 5 December 2019, the Organisation engaged a cybersecurity expert company (“CSE”) to conduct a thorough assessment of the Incident. The CSE found that: (a) the attacker had likely discovered the open RDP Port following a random, opportunistic search for vulnerabilities; and; (b) having discovered the open RDP Port, it was likely that the attacker used brute force attacks to obtain the administrator account password for the Server in order to gain access to the Server and execute the ransomware. 9 In total, the personal data of approximately 110,080 Participants, and 253 Employees were affected by the Incident (the “Affected Personal Data”). 10 For the affected Participants, the following categories of personal data were affected: (a) Name; 2 11 (b) NRIC number; (c) Address; (d) Race; (e) Gender; (f) Date of Birth; (g) Age; (h) Email address; (i) Contact number; (j) Course details; (k) Nationality; and (l) Employer details and past employment history. For the affected Employees, the following categories of personal data were affected: (a) Name; (b) NRIC number; (c) Date of Birth; (d) Nationality; (e) Citizenship; (f) Age; (g) Contact number; (h) Vehicle licence plate; and 3 (i) Financial Information (including salary/payment information, Central Provident Fund (“CPF”) information, and bank account numbers. 12 Not all of the above categories of personal data were affected in every individual’s case. For instance, the bulk of the affected Participants (approximately 98,000) only had their names and NRIC numbers stored on the Server. 13 The CSE’s investigation found no evidence of any exfiltration of the Affected Personal Data from the Server. The Organisation also managed to retrieve all the Affected Personal Data as most of the affected files were back-up files. 14 Upon being made aware of the Incident, the Organisation took prompt remedial actions. The Organisation: (a) Decommissioned the Server (without paying the ransom), and isolated the Server from its network and the Internet; (b) Notified the Commission, SingCERT, and all the affected Employees and Participants that it was able to (approximately 95%) of the Incident; and (c) 15 Issued a media advisory on the Incident. The Organisation also carried out actions to prevent a recurrence of the Incident. It: (a) Adopted its own internal password management policy; (b) Permanently disconnected and blocked remote access for IT support procedures; (c) Implemented Internet separation measures for all devices containing personal data; (d) Introduced various endpoint enhancements and gateway security measures including a monitoring system for all Internet-facing traffic, a suite of antivirus and malware protection for all computers and enhancing email hosting security protection and hard disk encryption; 4 (e) Engaged external IT security consultants to establish an Information Security Management Framework based on the ISO 27001 certification; (f) Conducted cybersecurity training sessions and cybersecurity awareness workshops for its staff; (g) Conducted ad-hoc email phishing tests to augment the cybersecurity training sessions and to engender greater awareness and vigilance towards suspicious emails; and (h) Put in place a monthly IT bulletin post to all employees to keep all staff up to date on IT and cybersecurity issues. Findings and Basis for Determination Whether the Organisation had contravened section 24 of the PDPA 16 Section 24 of the PDPA requires an organisation to protect personal data in its possession or under its control by taking reasonable security steps or arrangements to prevent unauthorised access, collection, use, disclosure, copying, modification, disposal or similar risks (“Protection Obligation”). 17 As a preliminary point, even though the Organisation had engaged the Vendor to maintain the Server and the Organisation’s other IT infrastructure, the scope of the Vendor’s engagement did not involve the processing or handling of any personal data on behalf of the Organisation. The Organisation owned the Server and was in possession and control of the Affected Personal Data at all material times. The Vendor was therefore not a data intermediary and the responsibility to protect the Affected Personal Data fell squarely on the Organisation. 18 For the reasons set out below, the Organisation failed to implement reasonable security arrangements to protect the Affected Personal Data from the risk of authorised access, modification and disposal. 5 Failure to adequately regulate remote access to the Server 19 First, the Organisation did not have sufficiently robust processes to ensure safe remote access to the Server via the RDP Port. The Remote Desktop Protocol (i.e., RDP) is a proprietary protocol developed by Microsoft Corporation for use in its Remote Desktop Connection application, which allows for remote connections to be established from one computer (i.e., a server) to another computer (i.e., the client) allowing the client to remotely control the server. By default, the server uses port number 3389 (i.e., the RDP Port) for incoming connections and requires authentication in the form of a username and password, before access to the server is granted. While the RDP Port is intended to be used for legitimate RDP client-server connections, its existence is well known and thus susceptible to be exploited by malicious actors to gain unauthorised access to a server if there are weak protective measures in place (e.g. weak user authentication). 20 While there is no strict requirement that the RDP Port must always be closed, organisations should regularly review and assess the potential risks of keeping such public facing ports open. Where it is necessary to keep the RDP Port on a server open, organisations should ensure that there are sufficient measures in place to protect the personal data stored on the server. 21 That said, where an organisation holds a high volume of personal data and/or highly sensitive personal data, the Commission is of the view that the default approach should be to close all ports, including RDP Ports. Where it is necessary to open the RDP Port, organisations must ensure that there are sufficient measures in place to ensure the security and legitimacy of any incoming RDP connection, and to promptly close the RDP Port upon completion of the required use. Additional measures to secure the files, for example, access control to folders and file encryption, may also be deployed. These are different layers of defences that can be used cumulatively or in different combination, depending on the volume and sensitivity of personal data and the requirements of business operations. 22 In this case, the Organisation kept the RDP Port open from the time the Server was set up in 2014 until the occurrence of the Incident on 4 December 2019. According 6 to the Organisation, the RDP Port was kept open to allow the Vendor quick remote access to the Server for recovery and maintenance works. The Organisation claimed that keeping the RDP Port permanently closed was not practicable, as half a day of down time would be required whenever the RDP Port needed to be opened or closed. 23 Given the fact that a minority of records (i.e. 253 Employees) contained more sensitive financial information and bank account numbers, as well as the volume of personal data stored on the Server, it is questionable whether the RDP Port should have been kept open permanently for recovery or maintenance work. Even if this meant incurring some down time in activating and deactivating the firewall for the RDP Port, the inconvenience associated with this down time should have been measured against the risk to the type and volume of personal data that was stored on the Server. Nonetheless, the benefit of doubt is given to the Organisation as the majority of records were personal particulars and contact information. 24 Even if it was necessary for the RDP Port to be kept open, the Organisation should at least have put in place other types of technical measures to secure the RDP access, such as: (a) Using a different port (other than the default port 3389) for RDP connections; (b) Restricting access to specific IP addresses or IP addresses within specified ranges, i.e. “whitelisting”; (c) using a RDP gateway; and/or (d) Conducting log reviews for unusual activity, whether upon automated alerts or scheduled monitoring. 25 The risks arising from poor management of RDP Ports have also been highlighted in the Cyber Security Agency of Singapore’s (“CSA”) recent advisory dated 28 December 2020, titled “Protect Your Systems and Data From Ransomware Attacks” 1 . The CSA similarly cautioned that some ransomware variants take 1 https://www.csa.gov.sg/singcert/advisories/ad-2020-006 7 advantage of exposed services and open ports such as the RDP Port to spread across a network. As such, in order to minimise the chance of a ransomware attack, the CSA emphasised that organisations should review their port settings, particularly, to assess whether there was a need to leave the RDP Port exposed, and if so, to restrict RDP connections to only trusted hosts. 26 The Organisation represented to the Commission that it would have been impractical to whitelist specific IP addresses as connections to the Server were generally made through dynamic, instead of static, IP addresses. Even so, the onus remained on the Organisation to put in place alternative security measures that were commensurate with the standard of protection required to protect sensitive data stored on the Server. However, the Organisation failed to implement any such alternative security measures. 27 The Organisation’s inaction on this front placed the Server at risk for more than four years - from the time the Server was set up in 2014 until it was disconnected from the Internet after the Incident. Failure to implement proper password management 28 Second, the Organisation failed to implement proper password management policies. The Organisation had adopted and generally directed its staff to follow the password policy of one of its affiliates (the “Password Policy”). The guidelines and standards in the Password Policy are consistent with the Commission’s recommendations in its Guide to Securing Personal Data in Electronic Medium2, which recommends that passwords used for authentication have a length of at least 8 characters, containing at least one alphabetical character and one numeric character. 29 However, the Organisation failed to take steps to ensure that the Password Policy was compiled with in practice. None of the passwords used by the Organisation for the administrator account of the Server or the files containing the Affected Personal Data (including those containing financial information) met the Password Policy’s recommended complexity rules. The passwords used by the Organisation also 2 https://www.pdpc.gov.sg/help-and-resources/2017/10/guide-to-securing-personal-data-in-electronic-medium 8 incorporated an acronym of the organisation’s name, which made them easy to guess and vulnerable to brute force attacks. 30 As noted in Re Chizzle Pte Ltd [2020] SGPDPCR 1 at [5(d)]: “In this regard, various articles/guides have stated that the use of an organisation’s name as a component of the password is not recommended because it is not difficult to guess and cracked by hackers. The digits “2018” as a component of the password was also guessable, for example, through brute force or dictionary attacks. As such, the password used by the Organisation failed to prevent unauthorised copying and deletion of the Chizzle Database.” [Emphasis added] 31 The login credentials for the administrator account on the Server were also shared between one administrator in the Organisation and at least three other individuals in the Vendor. Other than the login credentials, there were no other access controls to the administrator account (e.g. 2FA or anti-hammering features). As previously stated in Re Orchard Turn Developments Pte Ltd [2017] SGPDPC 12 (at [31]) user accounts should generally not be shared between different individuals, and all the more so for administrator accounts: “Additionally, there should not be a sharing of credentials amongst users. When credentials are shared among multiple users, it is difficult to ensure accountability as it is difficult to track the activity of each individual using the common set of credentials.” [Emphasis added] 32 Although the sharing of the administrator account credentials was not a direct contributing factor to the Incident, the sharing of account credentials – in particular, administrator accounts with high privileges – created an additional risk factor which could have diminished the robustness of other security measures put in place by the Organisation. 9 33 Similarly, while strong passwords may only slow but not entirely deter threat actors, the absence of strong passwords could greatly facilitate unauthorised access to IT systems, including IT systems holding personal data. Failure to take reasonable steps to ensure that the Vendor would protect personal data 34 Thirdly, while the Organisation claims to have relied on the Vendor’s technical expertise with regard to the security of the Server, the Organisation did not take reasonable or sufficient steps to stipulate clear requirements of its Vendor to ensure that the Vendor understood its role in the protection of the personal data in the Server. 35 As mentioned in the Commission’s Guide to Managing Data Intermediaries3: “The primary means by which a DC (i.e. a Data Controller) may ensure appropriate protection and retention of the personal data processed by its DI (i.e. a Data Intermediary) is through a contract. As the range of data processing activities that can potentially be outsourced is very broad, it is necessary for the scope of outsourced data processing activities to be clearly defined and agreed upon. There should be clear communication between the DC and the DI on the scope of outsourced data processing activities and the personal data requirements. For the DC, this is crucial in ensuring that its business requirements and management decisions in relation to the outsourcing are made clear to the DI.” 36 The Vendor in this case was not a Data Intermediary. However, the Vendor was nevertheless expected to handle personal data in the course of its work or make decisions which affected the security of personal data stored in the Server 4. As such, in order for the Organisation to say that it had discharged its Protection Obligation by relying on the Vendor’s technical expertise, clear business requirements on the protection of the data in the Server should have been specified. Alternatively, the Vendor could have made recommendations on the data protection requirements based on its understanding of the engagement (including for protection of the data in the Server), which the Organisation could have approved and adopted. In either case, 3 4 https://www.pdpc.gov.sg/Help-and-Resources/2020/09/Guide-to-Managing-Data-Intermediaries See Civil Service Club [2020] SGPDPC 15 at [13] and [14] 10 reasonable efforts should have been taken by the Organisation to verify that the Vendor was meeting its data protection requirements. 37 The exact requirements for a given case would depend on the services that a vendor is engaged to provide. If a vendor is engaged to put in place protection features for a Data Controller’s IT systems, the business requirements should describe the risks that the vendor is to address. In this case, the Organisation’s contract with the Vendor did not specify any business requirements for the protection of personal data in the Server. Neither could the Organisation provide any evidence to suggest that the Vendor made any recommendations about how to protect the data in the Server. As such, the Organisation could not say that it had discharged its Protection Obligation by relying on the expertise of the Vendor. 38 In the circumstances, the Commissioner finds that the Organisation failed to make reasonable security arrangements to protect the personal data in the Server from the risk of unauthorised access, modification and disposal. Accordingly, the Commissioner finds the Organisation in breach of its obligation under section 24 of the PDPA. The Commissioner’s Directions 39 In determining whether any directions should be imposed on the Organisation under section 48I of the PDPA, and/or whether the Organisation should be required to pay a financial penalty under section 48J of the PDPA, the factors listed at section 48J(6) of the PDPA and the following aggravating and mitigating factors were taken into account: Aggravating Factor (a) the Organisation’s failure to put in place reasonable security measures put the personal data in the Organisation’s possession and/or control at risk of exposure for more than four years. The failure to protect led to the unauthorised access and modification of the personal data in the Incident; 11 Mitigating Factors (b) the Organisation took prompt remedial actions following the Incident; and (c) 40 the Organisation was cooperative during the investigations. Having considered all the relevant factors of this case, including representations made by the Organisation on 1 April 2021 after being notified of the Commissioner’s Preliminary Decision, the Commissioner hereby directs the Organisation to pay a financial penalty of $35,000 within 30 days from the date of the relevant notice, 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. 41 In view of the remedial actions that have already been taken by the Organisation, no other directions are necessary. YEONG ZEE KIN DEPUTY COMMISSIONER FOR COMMISSIONER FOR PERSONAL DATA PROTECTION 12 ",Financial Penalty,65d2d1e1ed47bb4f1dba6c7af5b321b1ae19c7c3,"[""tags"",""decision"",""pdf-url"",""description"",""date"",""timestamp"",""url"",""title"",""nature"",""pdf-content""]" 2023-10-01T11:02:10+08:00,fbd32491db44d3d0c97aa12a99cefd61ec954264,61,61,1,1016,"A financial penalty of $8,000 was imposed on ST Logistics for failing to put in place reasonable security arrangements to prevent the unauthorised access of 2,400 MINDEF and SAF personnel's personal data.","[""Protection"", ""Financial Penalty"", ""Transport and Storage"", ""Phishing"", ""Malware""]",2021-06-10,https://www.pdpc.gov.sg/-/media/Files/PDPC/PDF-Files/Commissions-Decisions/Decision---ST-Logistics-Pte-Ltd---26102020.pdf,Protection,Breach of the Protection Obligation by ST Logistics,https://www.pdpc.gov.sg/all-commissions-decisions/2021/06/breach-of-the-protection-obligation-by-st-logistics,2021-06-10,"PERSONAL DATA PROTECTION COMMISSION [2020] SGPDPC 19 Case Nos. DP-1912-B5514 and DP-1912-B5559 In the matter of an investigation under section 50(1) of the Personal Data Protection Act 2012 And ST Logistics Pte Ltd … Organisation DECISION ST Logistics Pte Ltd [2020] SGPDPC 19 Lew Chuen Hong, Commissioner — Case Nos. DP-1912-B5514 and DP1912-B5559 26 October 2020 Introduction 1 Phishing attacks are increasingly prevalent and are one of the top cybersecurity threats faced by organisations1. In its latest report, the Cyber Security Agency of Singapore reported 47,500 cases of phishing in Singapore last year, almost triple the number of cases in 20182. This case is yet another example of an organisation falling victim to phishing. 2 On 16 December 2019, ST Logistics Pte Ltd (the “Organisation”) notified the Personal Data Protection Commission (the “Commission”) that the Organisation had detected an Emoted malware (“Emotet”) in their network which had infected 6 of its users’ laptops (including 4 laptops containing personal data), potentially affecting up to 4,000 individuals in the Ministry of 1 Phishing is a method employed by cyber criminals, often disguising themselves as legitimate individuals or reputable organisations, to fraudulently obtain personal data and other sensitive or confidential information. Once cyber criminals obtain an individual’s personal data, they may gain access to the individual’s online accounts and may impersonate the individual to scam persons known to the individual. See Cyber Security Agency of Singapore, Cyber Tip – Spot Signs of Phishing (25 February 2020) https://www.csa.gov.sg/gosafeonline/go-safe-forme/homeinternetusers/spot-signs-of-phishing. 2 See “Phishing attacks last year tripled from 2018”, The Straits Times, 27 June 2020. ST Logistics Pte Ltd [2020] SGPDPC 19 Defence (“MINDEF”) and Singapore Armed Forces (“SAF”) (the “Incident”). Subsequently, on 23 December 2019, the Commission received a complaint from an individual affected by the Incident. Facts of the Case 3 The Organisation provides logistical services to Singapore’s government and defence sectors, as well as commercial sectors. It has more than 800 employees worldwide and an annual revenue of approximately S$350 million3. 4 On 2 October 2019, the Organisation’s users received phishing emails from email addresses with the text “Stlogs” in the sender name field (e.g. “Account Executive (Stlogs)” and “Assistant General Manager (Stlogs)”). Each email contained an attachment with the file extension “doc”. A total of 13 users from the Organisation opened the malicious attachment (the “Affected Users”). 7 Affected Users had the Palo Alto Traps software (“Traps Software”), an advanced endpoint protection solution, installed in their laptops and were therefore protected from Emotet. The remaining 6 Affected Users (“Infected Users”) did not have Traps Software installed in their laptops. This resulted in the Incident with Emotet being installed and executed on the laptops of the Infected Users. Emotet subsequently harvested the emails in the Infected Users’ accounts, created approximately 100 new phishing emails, and sent these new phishing emails on 3 October 2019. Those new phishing emails quoted the bodies of real emails in the email accounts of the Infected Users. 5 Unencrypted files containing personal data were stored in 4 of the Infected Users’ laptops. The files were offline working copy files used in relation to the logistics services provided by the Organisation to the MINDEF 3 . 2 ST Logistics Pte Ltd [2020] SGPDPC 19 and SAF. The working files contained personal data relating to a total of 2,400 MINDEF and SAF personnel (“Affected Individuals”). The types of personal data of the Affected Individuals at risk of unauthorised access (collectively, the “Disclosed Data”) were: (a) Names; (b) Mailing addresses; (c) Email addresses; (d) Telephone numbers; and (e) NRIC numbers (1,320 full NRIC numbers and 1,080 masked (last 3 digits and checksum) NRIC numbers). 6 Based on the Organisation’s investigations (including anti-virus scans performed following the Incident), the infection by Emotet was limited to the laptops of the Infected Users. At the time of the Incident, the Organisation’s proxy logs captured information which showed that some exfiltration had taken place. However, there was insufficient information in the proxy logs to confirm that the exfiltration included files containing the Disclosed Data. 7 Upon discovery of the Incident, the following remedial actions were taken to mitigate the effects of the Incident: (a) The Organisation immediately disconnected the Infected Users laptops from the Organisation’s corporate network; (b) Security advisories (including guidelines on how to identify phishing emails) were sent to all the Organisation’s users to inform them of the Incident and to be vigilant; and 3 ST Logistics Pte Ltd (c) [2020] SGPDPC 19 All Affected Individuals were notified by MINDEF through text messages by 27 December 2019. 8 In addition, the following remedial actions have been taken, or are committed to be taken, by the Organisation to prevent recurrence of the Incident or similar incidents. (a) The Organisation conducted a “PDPA awareness” programme in February 2020 for its staff. “PDPA awareness” training materials were made available to all staff on the Organisation’s intranet. Selected users also attended the PDPA training offered by NTUC Learning Hub in February 2020; (b) Malicious email domains were identified. Enhanced firewall protection was implemented to inspect traffic to the Organisation’s email gateway. Email rules were created to block similar phishing emails from reaching the Organisation’s users; (c) The Organisation performed a company-wide validation exercise to ensure that Traps Software was installed on the laptops of all its users; (d) The Organisation conducted a Sender Policy Framework verification to reduce the number of spam and phishing emails reaching its users; (e) The Organisation implemented the display of warning banners for emails that do not originate from the Organisation’s email server; (f) The Organisation will increase the frequency of sending “Cybersecurity Advisory & Personal Data Protection Awareness” notices to all users; 4 ST Logistics Pte Ltd (g) [2020] SGPDPC 19 The Organisation implemented internet separation via URL filtering and has been exploring a sandbox feature and URL checking for all emails; (h) Periodic phishing exercises will be conducted as part of the Organisation’s Cybersecurity Awareness Program; and (i) Independent security experts will be engaged to perform compromise assessment to validate the security status of the Organisation’s systems environment in the third quarter of 2020. The Commissioner’s Findings and Basis for Determination 9 Most phishing attacks are sent by email,4 and the most common form is the general, mass-mailed type, where the cyber attacker sends an email pretending to be someone else and tries to trick the email recipient to log into a website or download malware.5 Based on the Commission’s past investigations, there are generally 2 scenarios when a data breach involves phishing attacks on e-mail accounts: (a) First, where malware harvests email addresses from the victim’s email address book to send further phishing emails to contacts of the victim. In this scenario, the only personal data that are accessed and used by the malicious actor are email addresses; and 4 https://www.cisco.com/c/en_sg/products/security/email-security/what-is-phishing.html; See also National Cyber Security Centre (United Kingdom), Phishing attacks: defending your organisation (version 1.1, 8 August 2019) https://www.ncsc.gov.uk/guidance/phishing: Phishing can be conducted via a text message, social media, or by phone, but the term 'phishing' is mainly used to describe attacks that arrive by email. 5 https://www.csoonline.com/article/3234716/types-of-phishing-attacks-and-how-to-identify- them.html 5 ST Logistics Pte Ltd (b) [2020] SGPDPC 19 Second, where the content of the victim’s email account is compromised, and emails are downloaded and/or forwarded by malicious actors. In this scenario, there may be personal data within the body of the email message (e.g. customer information, employee human resource data, payroll information etc.) as part of its communication content. Some of these may be confidential or commercially sensitive information. 10 The first type of email phishing attack at [9(a)] is more common, and the risk of harm is relatively low as the unauthorised access and use is limited to email addresses. Conversely, while the second type of email phishing attack at [9(b)] is less common, the risk of harm is significantly greater. This is because in addition to email addresses, communication content exposed to unauthorised access and use may contain other type(s) of personal data (including those of a sensitive nature, e.g. medical and financial data). Consequentially, a breach of data protection obligations resulting in the organisation falling victim to the second type of email phishing attack generally results in more serious consequences. 11 The present case falls into the first type of email phishing attack, and the issue for determination is whether the Organisation had complied with its obligations under Section 24 of the Personal Data Protection Act 2012 (the “PDPA”). Section 24 of the PDPA requires an organisation to protect personal data in its possession or under its control by making reasonable security arrangements to prevent unauthorised access, collection, use, disclosure, copying, modification or similar risks (the “Protection Obligation”). 12 As a preliminary point, it is not disputed that the Organisation was in possession and control of the Disclosed Data at all material times, and was obliged to put in place reasonable security arrangements to protect the Disclosed Data. 6 ST Logistics Pte Ltd 13 [2020] SGPDPC 19 The Commission’s investigations revealed that the Organisation failed to conduct periodic security reviews to detect vulnerabilities in its IT systems. (a) As stated in the Commission’s previous decisions, organisations are expected to conduct periodic security reviews of its IT systems.6 Conducting regular information and communication technology (“ICT”) security audits, scans and tests to detect vulnerabilities help organisations to ensure that ICT security controls developed and configured for the protection of personal data are properly implemented7. The comprehensiveness of such security reviews should be scoped based on the organisation’s assessment of its data protection needs, and be conducted to a reasonable standard; (b) In the present case, a reasonably conducted security review should have included (i) verifying complete installation and proper configuration of the security software on all of the Organisation’s users’ laptops; and (ii) checking that the security software is updated; (c) The Organisation’s failure to conduct a security review to a reasonable standard resulted in the following undetected security gaps that led to the Incident8: (i) The anti-virus software installed on users’ laptops was not updated because they had not been properly configured to receive updates. This security gap affected all of the Infected Users, whose laptops were not so configured. The investigations 6 See Re WTS Automotive Services Pte. Ltd. [2018] SGPDPC 26 at [18], Re Bud Cosmetics [2019] SGPDPC 1 at [24] and Re Chizzle Pte. Ltd. [2019] SGPDPC 44 at [6] to [8]. 7 Commission’s Guide to Securing Personal Data in Electronic Medium (revised 20 January 2017) at [6.1]. 8 As an updated anti-virus software and Traps Software both offered protection against Emotet, the Organisation could have chosen to take a phased approach to its security review. 7 ST Logistics Pte Ltd [2020] SGPDPC 19 into the Incident revealed that if anti-virus software had been updated, it would have been able to block and remove Emotet at the material time; and (ii) Due to a rollout gap, the Traps Software was not installed on the laptops of some Organisation’s users. In contrast with signature-based anti-virus software (which is used to identify “known” malware), Traps Software detects malware based on their behaviour. This enables Traps Software to detect newly released forms of malware (which signature-based anti-virus software may potentially fail to detect) based on behavioural analysis. As mentioned at [4], this security gap affected all of the Infected Users, on whose laptops the Traps Software had not been installed. Conversely, the laptops of the remaining 7 Affected Users (who had also opened the malicious attachment) had Traps Software installed, and were accordingly protected from Emotet. 14 Based on the Commission’s preliminary findings, it appeared that the Organisation also did not conduct proper data protection training for its staff. In particular, the Organisation had conceded during investigations that not all the Affected Users had completed the relevant data protection training at the time the Incident occurred. The failure to conduct proper data protection training would have been an additional ground (other than the omission to conduct periodic security reviews to detect vulnerabilities in the IT system) in support of finding the Organisation in breach of the Protection Obligation. 15 However, the Organisation subsequently clarified in its representations to the Commission’s preliminary findings that its data protection training for its staff prior to the Incident included PDPA awareness programmes conducted in March and April 2019 and bi-monthly staff induction programmes covering 8 ST Logistics Pte Ltd [2020] SGPDPC 19 cybersecurity and PDPA compliance. In addition, the training material for the PDPA awareness programme, as well as relevant reference materials and the URL link to the Commission’s website were provided in the Organisation’s intranet to allow staff ready access to data protection related resources. 16 The Commission recognises that staff movement will always have to be factored into staff training programmes, and at any one point in time, there will always be members of staff at different stages of training. Having a training programme in place and a system to track staff training is therefore important. Thus, while not all the Affected Users had completed the relevant data protection training at the time of the Incident, the arrangements the Organisation had implemented towards trainings its staff on data protection was reasonable in the circumstances. 17 For the reasons set out at [13] above, the Commissioner finds the Organisation in breach of section 24 of the PDPA. 18 In addition to the representations made on data protection training, the Organisation also raised the following factors for consideration in support of a reduction in the quantum of financial penalty which the Commissioner intended to impose: (a) The Organisation had put in place reasonable security arrangements to protect the Disclosed Data prior to the Incident. These included advanced end point solution (Palo Alto Traps) on corporate servers and workstations; privileged access management; monitoring of security events through security information and events management systems; and web penetration test performed for corporate applications by CREST accredited vendor. Notwithstanding these arrangements, the Organisation was a victim of a phishing attack; and 9 ST Logistics Pte Ltd (b) [2020] SGPDPC 19 There was a low risk of harm arising from the Incident as the unauthorised access and use of the Disclosed Data by the cyber attacker were limited to email addresses. There was also no evidence that any Disclosed Data had been exfiltrated. 19 The Organisation’s representations that it had put in place reasonable security arrangements to protect the Disclosed Data prior to the Incident is not accepted. As explained at [13], the Organisation failed to conduct periodic security reviews to detect vulnerabilities in its IT systems. The requirement for organisations to conduct periodic security reviews to comply has been emphasised in the Commission’s previous decisions.9 Separately, the Organisation’s representation that there was a low risk of harm arising from the Incident is accepted and has been taken into account in determining the financial penalty. 20 Having carefully considered the representations, the Commissioner has decided to reduce the financial penalty to the amount set out at [22]. The quantum of financial penalty has been determined after due consideration of the low risk of harm arising from the Incident and the mitigating factors set out at [21]. The Commissioner’s Directions 21 In determining the directions, if any, to be imposed on the Organisation under Section 29 of the PDPA, the Commissioner took into account the Organisation’s cooperation with the investigations and its prompt and forthcoming responses to the Commission’s queries. 9 See cases listed at Footnote 6. 10 ST Logistics Pte Ltd 22 [2020] SGPDPC 19 Having considered all the relevant factors of this case, the Commissioner directs the Organisation to pay a financial penalty of S$8,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 the financial penalty until it is paid in full. The Commissioner has not set out any further directions given the remediation measures already put in place. YEONG ZEE KIN DEPUTY COMMISSIONER FOR COMMISSIONER FOR PERSONAL DATA PROTECTION 11 ",Financial Penalty,50724d913acafbfd43b21653cd18c545ba471871,"[""tags"",""decision"",""pdf-url"",""description"",""date"",""timestamp"",""url"",""title"",""nature"",""pdf-content""]" 2023-10-01T11:02:10+08:00,fbd32491db44d3d0c97aa12a99cefd61ec954264,62,62,1,1016,A warning was issued to Greatearth Corporation for failing to obtain consent to disclose personal data of 8 crane operators on the external façade of a construction site.,"[""Consent"", ""Warning"", ""Construction"", ""Consent"", ""Ban list"", ""Acting in Course of Employment""]",2021-05-12,https://www.pdpc.gov.sg/-/media/Files/PDPC/PDF-Files/Commissions-Decisions/Decision---Progressive-Builders-and-Greatearth-Corporation---16042021-(002).pdf,Consent,"Breach of the Consent Obligation by Greatearth Corporation, No Breach of the PDPA by Progressive Builders",https://www.pdpc.gov.sg/all-commissions-decisions/2021/05/breach-of-the-consent-obligation-by-greatearth-corporation,2021-05-12,"PERSONAL DATA PROTECTION COMMISSION [2021] SGPDPC 2 Case No. DP-1907-B4305 In the matter of an investigation under section 50(1) of the Personal Data Protection Act 2012 And (1) Progressive Builders Private Limited (2) Greatearth Corporation Pte. Ltd. … Organisation DECISION 1 (1) Progressive Builders Private Limited; (2) Greatearth Corporation Pte. Ltd. [2021] SGPDPC 2 Yeong Zee Kin, Deputy Commissioner — Case No. DP-1907-B4305 16 April 2021 Introduction 1 This case involves a series of incidents that led to the unauthorised collection, use, and disclosure of the personal data of 8 individuals (the “Complainants”) by Greatearth Corporation Pte. Ltd. (“GCPL”). On 19 and 20 July 2019, the Personal Data Protection Commission (the “Commission”) received complaints from each of the Complainants alleging that their personal data had been disclosed by Progressive Builders Private Limited (“PBPL”) without their consent (the “Complaints”). The Commission commenced an investigation into the Complaints. Facts of the Case 2 The Complainants are tower crane operators engaged by Craneworks Pte Ltd (“the Subcontractor”) to operate tower cranes for the Subcontractor’s clients, including PBPL. PBPL is the main contractor for a housing project in Geylang (the “Geylang Project”) and is in charge of the Geylang Project worksite (the “Geylang Worksite”). PBPL had collected the Complainants’ personal data (including their full name, NRIC, contact number and photograph) when they were appointed as tower crane operators for the Geylang Project. The collection of their personal data was for the purposes of managing the Complainants’ roles as tower crane operators. The Subcontractor is a sub-contractor of PBPL for the Geylang Project. It supplies licensed crane operators to PBPL for the operation of tower cranes. 3 GCPL is also a company that is in the construction business. It is the main contractor for a housing project in Clementi (the “Clementi Project”) and is in charge of the Clementi 2 Project worksite (“Clementi Worksite”). GCPL does not have any business relationship with PBPL, the Subcontractor, or the Complainants. Creation of the Banned Operators List 4 Between 12 and 18 July 2019, a series of incidents involving the Complainants and the staff of PBPL occurred at the Geylang Site. As a result of the incidents, PBPL banned the Complainants from entering the Geylang Worksite. After the workplace incidents, PBPL’s project director (“Project Director”) directed PBPL’s Workplace Safety & Health Officer (“WSHO”) at the time to compile a list of the Complainants’ details, which included the following personal data of each of the Complainants: (a) Full name; (b) NRIC number; (c) Contact number; and (d) Photo ID of the individual (collectively, the “Banned Operators List”). 5 According to PBPL, the Banned Operators List was created to identify the Complainants that were involved in the workplace incidents and sent to the Subcontractor and the Ministry of Manpower to inform them of the individuals involved in the workplace incidents. Disclosure of the Banned Operators List 6 On or about 17 July 2019, unbeknownst to PBPL and without any authorisation from PBPL, PBPL’s WSHO sent the Banned Operators List to a private Whatsapp group comprising of workplace safety professionals in Singapore (the “Whatsapp Group”) along with the following Whatsapp message: “… [details of the incident]. Please look out for such operators in future at your site.” 3 7 The Complaints were filed with the Commission between 19 and 20 July 2019 after the Complainants came to know of the existence of the Banned Operators List and the fact that it was being circulated amongst those in the construction industry. 8 GCPL’s WSHO was a member of the Whatsapp Group. When GCPL’s WSHO received the Banned Operators List and message, he understood it to mean that the individuals listed in the Banned Operators List (i.e. the Complainants) were banned from working at the Geylang Worksite. As he oversaw the Clementi Worksite, he wanted to look out for the Complainants should they come onto the Clementi Worksite. 9 On or about 24 July 2019, GCPL’s WSHO sent the Banned Operators List to GCPL’s safety coordinator with instructions “to look out for these people and not to let them enter the Clementi worksite”. Specifically, GCPL’s WSHO instructed GCPL’s safety coordinator to print and paste a copy of the Banned Operators List in the guard room so that the security guards could keep a lookout for the Complainants. However, GCPL’s safety coordinator misunderstood these instructions. Instead of pasting a copy of the Banned Operators List in the guard room of the Clementi Worksite, the word “BANNED” was added as a header to the Banned Operators List and the list was pasted on the external façade of the Clementi Worksite where it was visible to all persons walking onto the Clementi Worksite (the “Poster”). 10 According to GCPL’s WSHO, he had not noticed that the Poster was pasted on the external façade of the Clementi Worksite as he usually drove into the worksite. While GCPL’s WSHO claimed to have only noticed the Poster on the external façade in late September 2019 and intended to remove it, GCPL only took down the Poster after the Commission notified it of the Complaints on or about 26 September 2019. The Poster had been displayed on the external façade for about 2 months. Findings and Basis for Determination 11 The issues to be determined in this case are: (a) whether PBPL is responsible for their WSHO’s disclosure of the Banned Operators List; (b) if PBPL is responsible, whether PBPL contravened its obligations under the Personal Data Protection Act 2012 (“PDPA”); 4 (c) whether GCPL is responsible for their WSHO and safety coordinator’s collection, use, and disclosure of the Banned Operators List; and (d) if GCPL is responsible, whether GCPL contravened its obligations under the PDPA. Whether PBPL is responsible for their WSHO’s disclosure of the Banned Operators List 12 Under section 53(1) of the PDPA, any act done, or conduct engaged in by an employee in the course of his employment is treated as done or engaged in by his employer as well, regardless of whether it was done or engaged in with the employer’s knowledge or approval. Section 53(2) provides for a defence of reasonable diligence for offences under the PDPA, where the employer had taken reasonable steps to prevent or reasonably reduce the risk of the occurrence of the employee’s action or conduct that resulted in an unauthorised collection, use and/or disclosure of personal data. For investigations into breaches of the PDPA that are not offences — such as the present case — a similar standard of reasonable diligence may be applied by virtue of section 11(1) of the PDPA, by considering whether the organisation had acted reasonably in meeting its responsibilities under the PDPA. 13 In the present case, the Commission’s investigations found that PBPL’s WSHO was not acting in the course of his employment when he disclosed the Banned Operators List to the members of the Whatsapp Group: (a) first, even though PBPL’s WSHO compiled the Banned Operators List in the course of his employment, there was no evidence that PBPL had directed him to share the Banned Operators List in the Whatsapp Group. PBPL was not aware of the Whatsapp Group’s existence and did not know that their WSHO was a member of the Whatsapp Group; and (b) second, in sharing and disclosing the Complainants’ personal data in the Banned Operators List to the members of the Whatsapp Group, PBPL’s WSHO had disregarded his obligations of confidentiality under his employment contract: “You shall keep confidential and not, during your employment, directly or indirectly use, divulge, disclose or deliver to any person except as authorized or required by your duties, or by law, and term in this letter of 5 any Confidential Information of the Company acquired by you in the course of your employment.” 14 Thus, given that PBPL’s WSHO acted outside of the course of his employment when he disclosed the Complainants’ personal data without their consent, section 53(1) of the PDPA does not apply and the WSHO’s actions cannot be attributed to PBPL. Accordingly, PBPL did not contravene its data protection obligations under the PDPA with regard to the disclosure of the Complainants’ personal data in the Banned Operators List. Whether GCPL is responsible for their WSHO and safety coordinator’s collection, use and disclosure of the Banned Operators List 15 Similar to PBPL, it is doubtful if GCPL knew of the existence of the WhatsApp Group or that it’s WSHO was a member thereof. GCPL’s WSHO probably also did not obtain the Banned Operators List in the course of his employment, since his participation in the WhatsApp Group was unsanctioned. However, the significant departure is that unlike PBPL’s WSHO, GCPL’s WSHO was acting in the course of his employment when he instructed GCPL’s safety coordinator to put up a copy of the Banned Operators List in the Clementi Worksite guardhouse. The use of the Complainants’ personal data was expressly professed to be for the purpose of screening and restricting the entry of the Complainants onto the Clementi Worksite. Similarly, GCPL’s safety coordinator was also acting in the course of his employment when he pasted the Poster on the external façade of the Clementi Worksite, thereby disclosing the Complainants’ personal data. 16 Accordingly, pursuant to section 53(1) of the PDPA, GCPL’s WSHO and safety coordinator’s collection, use, and disclosure of the Complainants’ personal data were the actions of GCPL for which it was responsible. Whether GCPL has contravened its obligations under the PDPA 17 Under section 13 of the PDPA, organisations are prohibited from collecting, using or disclosing an individual’s personal data unless the individual gives, or is deemed to have given, his consent for the collection, use or disclosure of his personal data, or the collection, use or disclosure without consent is authorised under the PDPA or any other written law (the “Consent Obligation”). 6 18 On the present facts, the disclosure of the Complainants’ personal data without their consent was not authorised under the PDPA or any other written law; nor could disclosure be supported by any extant exceptions for the Consent Obligation. It was clear from the facts that the Complainants had not voluntarily provide their personal data to GCPL. GCPL therefore needed to have obtained the Complainants’ consent before disclosing their personal data by pasting the Banned Operators List onto the façade of the Clementi Worksite. However, GCPL failed to do so. 19 While it is arguable that the use of the Banned Operators List within the guardroom and confined to the security personnel may have been acceptable, especially if the context of the information had been provided and clear instructions had been given that the Banned Operators List be restricted to private reference by security personnel on duty. However, the present case went beyond what a reasonable person would consider appropriate in the circumstances. The information came from an informal source – i.e. the WhatsApp Group – and GCPL made a decision to ban the Complainants from the Clementi Worksite on the basis of the Banned Operators List. These are decisions that GCPL may make as a private commercial enterprise. The Banned Operators List could have been handled more discretely and used more responsibly. However, pasting it on the external façade of the Clementi Worksite such that it could be seen any passer-by fell below the standard of reasonableness that is expected from GCPL. 20 In the circumstances, GCPL breached the Consent Obligation. The Deputy Commissioner’s Directions 21 In determining the directions, if any, to be imposed on GCPL under section 48I of the PDPA, I took into account the following mitigating factors: (a) the incident occurred because GCPL’s safety coordinator (who was a new employee at the time) misunderstood the instructions given to him; (b) the incident had originated from GCPL’s WSHO whose actions arose out of concern for the safety of the Clementi Worksite, in view of the alleged conduct of the Complainants, and in the interest of his employer; 7 (c) there was limited disclosure of personal data of the Complainants and any disclosure would have been limited to those who entered the Clementi Worksite on foot; and (d) upon being notified of the Complaints, GCPL took prompt remedial action by removing the Banned Operators List poster from the Clementi Worksite. 22 Having considered all the relevant factors of this case, I hereby issue a Warning to GCPL. No further directions are necessary given the remedial actions that have already been taken by GCPL. YEONG ZEE KIN DEPUTY COMMISSIONER FOR PERSONAL DATA PROTECTION 8 ",Warning,3df9d84ac2b94b9eceb608d856f98239db7a49bc,"[""tags"",""decision"",""pdf-url"",""description"",""date"",""timestamp"",""url"",""title"",""nature"",""pdf-content""]" 2023-10-01T11:02:10+08:00,fbd32491db44d3d0c97aa12a99cefd61ec954264,63,63,1,1016,A review application under section 28 (now known as section 48H(1)(a)) of the PDPA was conducted following a failed request by an individual to obtain his full unredacted internal evaluation report prepared by HSBC Bank (Singapore) Limited for the purpose of evaluating his credit card application.,"[""Finance and Insurance"", ""Access and Correction"", ""Evaluation"", ""Opinion Data""]",2021-05-12,https://www.pdpc.gov.sg/-/media/Files/PDPC/PDF-Files/Commissions-Decisions/Decision--HSBC-Bank-Singapore-Limited--10032021.pdf,,Outcome of a Review Application Involving an Individual and HSBC Bank,https://www.pdpc.gov.sg/all-commissions-decisions/2021/05/outcome-of-a-review-application-involving-an-individual-and-hsbc-bank,2021-05-12,"PERSONAL DATA PROTECTION COMMISSION [2021] SGPDPC 3 Case No. DP-1810-B2892R In the matter of a review under section 48H(1)(a) of the Personal Data Protection Act 2012 and of the Personal Data Protection (Enforcement) Regulations 2021 Between [Redacted] … Applicant And HSBC Bank (Singapore) Limited … Respondent DECISION HSBC Bank (Singapore) Limited Yeong Zee Kin, Deputy Commissioner — Case No. DP-1810-B2892R 10 March 2021 Background 1 The Respondent, HSBC Bank (Singapore) Limited (“HSBC”), is a full-service bank in Singapore. HSBC’s personal banking offerings include credit card facilities to individuals, offered subject to a process of application and approval by the bank. Sometime in 2018, the Applicant applied to HSBC for a credit card, but was unsuccessful. Dissatisfied, he requested HSBC to provide him with a copy of the bank’s internal evaluation report prepared for the purpose of evaluating his credit card application (“the Report”). 2 In response to the Applicant’s request, HSBC furnished a copy of the Report but with some fields redacted (“the Redacted Data”). HSBC’s position was that they were not obliged to disclose the Redacted Data to the Applicant, as the Redacted Data constituted opinion data kept solely for an evaluative purpose, an exception to the Access Obligation under paragraph 1(a) of the Fifth Schedule (“the Evaluative Purpose Exception”). 3 The Applicant maintained that he was entitled to the full unredacted Report, and approached the Personal Data Protection Commission (the “Commission”) for assistance. The Commission attempted to facilitate an amicable resolution between the parties. When attempts to facilitate an amicable resolution were unsuccessful, the Commission informed the Applicant of his option to make a review application under the then section 28 of the PDPA (now, section 48H(1)(a) of the PDPA) (“the Review Application”). 4 The Applicant elected to take this option on 18 March 2020. As HSBC’s position on the Review Application was extensively set out in its prior correspondence with the Commission, these were (with HSBC’s consent) treated as the Respondent’s response for the purposes of Regulation 6 of the Personal Data Protection (Enforcement) Regulations 2014 (“the Response”). In the Response, in addition to the Evaluative Purpose Exception, HSBC cited additional grounds to justify not disclosing the Redacted Data to the Applicant. Despite the Commission’s invitation, the Applicant did not submit any reply to the Response. Findings and basis for determination 5 The issues that arise for my determination in this Review Application are: (a) Whether the Report is personal data of the Applicant; and (b) If so, whether the Evaluative Purpose Exception (or any other exception under the PDPA or other written law) applies so as to justify HSBC’s refusal to give the Applicant access to the Redacted Data. The Access Obligation 6 The Applicant’s request for access to the Report should be viewed as a data subject access request made pursuant to section 21(1) of the Personal Data Protection Act 2012 (“PDPA”). Section 21(1) of the PDPA gives a data subject the right to access personal data about him that is in an organisation’s possession or under its control (“the Access Obligation”). The data subject’s right of access is moderated by section 21(2) of the PDPA which allows an organisation to invoke any of the exceptions listed in the Fifth Schedule of the PDPA to decline the data subject access request. 7 The Access Obligation should not be examined in isolation. The Access Obligation enables a number of neighbouring obligations: the Purpose Limitation Obligation (section 18 of the PDPA), the Correction Obligation (section 22 of the PDPA) and the Accuracy Obligation (section 23 of the PDPA). The Access Obligation enables the data subject to ascertain what personal data about him an Organisation possesses or controls, and also how it has been used or disclosed. It empowers the data subject to ask for an account of how personal data about him has been collected, used or disclosed: section 21(1)(b) of the PDPA. It also enables the data subject to ascertain that personal data about him is correct, and to request for correction of errors or omissions: section 22(1) of the PDPA. This in turn supports the organisation’s use of personal data. The Accuracy Obligation requires an organisation to ensure that personal data that it uses when making decisions that affect an individual is accurate and complete: section 23(a). 2 8 The PDPA respects a fundamental distinction between ensuring that good quality data is available to organisations that make use of them to make decisions, and the decision and decision-making process. Whereas the Access and Correction Obligations support the former by empowering the individual in the manner described in the preceding paragraph, the Fifth and Sixth Schedules contain a number of exceptions that are intended to preserve the confidentiality of the decision-making process e.g. evaluative purpose and trust administration. 9 I thought it helpful to preface the relationships of these obligations before providing the reasons for my decision on this Review Application. Is the Report personal data of the Applicant? 10 Section 2(1) of the PDPA defines “personal data” as data, whether true or not, about an individual who can be identified (a) from that data; or (b) from that data and other information to which the organisation has or is likely to have access. In the Commission’s Advisory Guidelines on Key Concepts in the PDPA, the following guidance has been provided on when data would be considered “personal data” for the purposes of the PDPA, at [5.2] and [5.4]: (a) The term “personal data” is not intended to be narrowly construed and may cover different types of data about an individual and from which an individual can be identified, regardless of whether such data is true or accurate, or whether the data exists in electronic or other form. (b) There are two principal considerations. First, is the nature or purpose of the information to be data about an individual or which relates to the individual. Second, the individual should be identifiable from the data on its own, or from that data and other information to which the organisation has or is likely to have access. 11 The Report was prepared for the purposes of evaluating the Applicant’s application for credit card facilities. It contained information about him that was relevant to deciding whether credit card facilities should be extended by HSBC. The Report contained various data fields, some of which were populated with text, and some left blank. Some of the populated fields in the Report were redacted by HSBC when a copy was provided to the Applicant (i.e. the Redacted Data). Since the Report contains information about the Applicant, who is identifiable from the information, and the Report was prepared for the purpose of making a decision 3 concerning his application for credit card facilities, the Report is therefore the personal data of the Applicant. 12 In its Response, HSBC described the Redacted Data as opinion data auto-generated by HSBC’s proprietary algorithm that determined an individual’s suitability for a credit card by analysing data from various sources. The data analysed included (i) information provided by the Applicant in his credit card application form such as his age, education level, income and employment information, and (ii) data obtained from third parties such as other banks or the Credit Bureau Singapore. HSBC also explained that the Redacted Data did not comprise of actual data from these sources, but was data derived from information obtained from these sources. 13 I did not consider the fact that the Redacted Data was algorithmically generated data to be relevant in determining whether they formed part of the Applicant’s personal data. The primary focus is whether the information is about an identified or identifiable individual. It matters not whether the data was collected directly from the data subject, from a third-party source or derived from data from either (or both) of such sources. So long as the information is about the individual and it is in the possession or under the custody of the organisation, it is personal data. 14 For the purpose of deciding the applicability of the Evaluative Purpose Exception subsequently, I need to be satisfied that the Redacted Data is opinion data. HSBC’s argument is that the Redacted Data was derived after an analysis of primary data based on business rules that are expressed in its proprietary algorithm. For the purpose of this Review Application, HSBC provided the Report in the clear. There are five fields that were redacted: four were algorithmically generated and one contained type-written information. I am satisfied that the Redacted Data is not merely a reproduction of personal data obtained from a third-party source nor are they the result of simple arithmetic operations; they are expressions of opinions after data processing. I therefore accept the argument that the application of business rules in the algorithmic analysis yielded opinions, and by virtue of this, the Redacted Data is opinion data. Therefore, the Redacted Data is opinion data that forms part of the Applicant’s personal data that HSBC has in its possession and control; and the Redacted Data is potentially subject to the Access Obligation, unless HSBC is able to rely on an applicable exception. 4 Can HSBC rely on the Evaluative Purpose Exception (or other grounds) to decline access to the Redacted Data? 15 The Fifth Schedule allows an organisation to decline providing access to “opinion data kept solely for an evaluative purpose”: para 1(a) of the Fifth Schedule. Section 2(1) of the PDPA defines “evaluative purpose” to mean: “(a) for the purpose of determining the suitability, eligibility or qualifications of the individual to whom the data relates — (i) for employment or for appointment to office; (ii) for promotion in employment or office or for continuance in employment or office; (iii) for removal from employment or office; (iv) for admission to an education institution; (v) for the awarding of contracts, awards, bursaries, scholarships, honours or other similar benefits; (vi) for selection for an athletic or artistic purpose; or (vii) for grant of financial or social assistance, or the delivery of appropriate health services, under any scheme administered by a public agency; (b) for the purpose of determining whether any contract, award, bursary, scholarship, honour or other similar benefit should be continued, modified or cancelled; (c) for the purpose of deciding whether to insure any individual or property or to continue or renew the insurance of any individual or property; or (d) for such other similar purposes as may be prescribed by the Minister” [emphasis added] 16 It is clear from the words emphasised in bold in the definition above that the Evaluative Purpose Exception is intended to cover the decision-making process: in other words, the evaluation before a decision is made. The definition enumerates a number of decisions that organisations have to make from time to time: see the words emphasised in italics. Thus, the Evaluative Purpose Exception operates to keep opinions that form part of the decision-making process confidential. Data subjects do not have the right to access personal data that is contained in such opinions: section 21(2) read with para 1(a) of the Fifth Schedule; nor do they have the right to request corrections: section 22(6) and 22(7) read with para 1(a) of the Sixth Schedule. 5 17 In the present Review Application, the Applicant had applied for credit card facilities. Limb (a) of the definition is the relevant one. HSBC is evaluating his suitability or eligibility for the credit card facilities. The evaluation will result in a decision whether to extend to him the credit card facilities that he had applied for, which will entail the award of a contract: i.e. sub-section (v) “for the awarding of contracts, awards, bursaries, scholarships, honours or other similar benefits”. The operative decision here is to make an award; the subject matter of the decision covers a range of things. Some are in the nature of a bilateral relationship, eg contracts, bursaries and scholarships; some a unilateral conferment of a status, eg honours or similar benefits. Thus, HSBC was using the opinion data to evaluate whether to award the contract to the Applicant. I therefore find that HSBC was entitled to rely on the Evaluative Purpose Exception to decline giving the Applicant access to the Redacted Data. 18 Section 21(5) of the PDPA contemplates occasions, such as the present, where documents may contain personal data that the data subject is entitled to access commingled with other personal data that the organisation may decline to provide access to. Thus, HSBC is entitled to rely on the Evaluative Purpose Exception to exclude the Redacted Data from the copy of the Report that was furnished to the Applicant. 19 Even though HSBC declined to disclose the Redacted Data, it had provided to the Applicant two publications: (a) HSBC’s Principle for the Ethical Use of Big Data and AI and (b) HSBC’s Credit Decisioning Policy Statement. These publications provide information about how AI and Big Data are used in an ethical manner by HSBC and how technology is used to conduct credit facility assessments. I found the Credit Decisioning Policy Statement relevant. It provides a description of the type of opinions that the majority of the Redacted Data conveyed. Even though HSBC was entitled to decline providing access to the Redacted Data, it had acted reasonably by providing information about how it uses data and technology to conduct credit facility assessments. From the perspective of accountability and disclosure of policies and practices, HSBC had acquitted itself. 20 For completeness, HSBC also cited various other reasons in its Response to justify its refusal to give the Applicant access to the Redacted Data. In view of my conclusion that HSBC was entitled to rely on the Evaluative Purpose Exception to decline providing access to the Redacted Data, it is unnecessary for me to consider these additional grounds put forth by HSBC 6 in full. Nevertheless, I set out these additional grounds and the reasons why I did not think that they merited full consideration: (a) Citing paragraph 1(g) of the Fifth Schedule of the PDPA, HSBC argued that disclosure of the Redacted Data would reveal confidential commercial information that would affect HSBC’s competitive position. From my perusal of the Report, I did not think that the Redacted Data would disclose or allow for the reverse-engineering of “confidential commercial information” pertaining to HSBC’s credit card application evaluation process that would affect its competitive position. On the contrary, their Credit Decisioning Policy Statement provided an ample description of the majority of the Redacted Data. (b) Citing paragraph 1(h) of the Fifth Schedule of the PDPA, HSBC argued that the Redacted Data was personal data collected for the purposes of an investigation and that this investigation and associated proceedings and appeals had not yet been completed. Based on the information provided, there was no ongoing ‘investigation” within the meaning of section 2(1) of the PDPA. Client due diligence or customer information checks for the purposes of a credit card application were not “investigations” in this sense. (c) Citing paragraph 1(j)(ii) of the Fifth Schedule of the PDPA, HSBC argued that the burden or expense of providing access to the Redacted Data would be unreasonable considering the volume of credit application applications that HSBC received daily. This was an assertion unsupported by evidence. It was not unreasonably burdensome or expensive for HSBC to respond to the Applicant’s access request, and the fact that the Applicant’s request might lead to other individuals making similar requests was not a relevant consideration. (d) Citing paragraph 1(j)(v) of the Fifth Schedule to the PDPA, HSBC argued that the Applicant’s request was frivolous and vexatious as the Applicant had full knowledge of the personal data and financial information that he had himself provided by way of his credit card application only some 2 weeks prior to his access request. I did not consider the Applicant’s request to be frivolous or vexatious as he had not requested for the same data which he had provided to HSBC in his credit card 7 application form, but had requested for the bank’s opinion data in the Report, which he had no knowledge of but was interested in. (e) Finally, HSBC argued that MAS Notice 626 issued on 24 April 2015 (pursuant to section 27B of the Monetary Authority of Singapore Act) took precedence over HSBC’s obligations under the PDPA by virtue of section 4(6) of the PDPA, and allowed HSBC to refuse access to the Redacted Data. MAS Notice 626 deals with anti-money laundering and terrorism financing. Having considered the Redacted Data in the clear, I did not think that this MAS Notice was relevant. The Deputy Commissioner’s Decision 21 Pursuant to section 48H(2)(a) of the PDPA, and for the reasons set out above, I confirm HSBC’s refusal to provide the Applicant with access to the Redacted Data. YEONG ZEE KIN DEPUTY COMMISSIONER FOR PERSONAL DATA PROTECTION 8 ",,c714658b21945c62deecbceeab6abcc2739aa9f8,"[""tags"",""decision"",""pdf-url"",""description"",""date"",""timestamp"",""url"",""title"",""nature"",""pdf-content""]" 2023-10-01T11:02:10+08:00,fbd32491db44d3d0c97aa12a99cefd61ec954264,64,64,1,1016,"A warning was issued to Flying Cape, a data intermediary, for failing to put in place reasonable security arrangements to protect the personal data of 191 users of a website. Flying Cape was managing the website on behalf of its client.","[""Protection"", ""Warning"", ""Information and Communications"", ""Ransomware"", ""Data Intermediary"", ""Online Storage Bucket""]",2021-04-15,https://www.pdpc.gov.sg/-/media/Files/PDPC/PDF-Files/Commissions-Decisions/Decision---Flying-Cape-Pte-Ltd---17032021.pdf,Protection,Breach of the Protection Obligation by Flying Cape,https://www.pdpc.gov.sg/all-commissions-decisions/2021/04/breach-of-the-protection-obligation-by-flying-cape,2021-04-15,"PERSONAL DATA PROTECTION COMMISSION Case No. DP-2011-B7385 In the matter of an investigation under section 50(1) of the Personal Data Protection Act 2012 And (1) Flying Cape Pte Ltd (2) ACCA Singapore Pte Ltd SUMMARY OF THE DECISION 1. Sometime between 25 September 2020 to 5 October 2020, the personal data of 191 users (the “Affected Individuals”) of www.accapdhub.com (the “Website”) was exfiltrated by an unauthorised party (the “Incident”).The exfiltrated personal data comprised of the names, email addresses and contact numbers of the Affected Individuals (“the Exfiltrated Data”). 2. The Website was owned by ACCA Singapore Pte Ltd (“ACCA”), but hosted, managed, and operated by Flying Cape Pte Ltd (“FCPL”) as ACCA’s data intermediary. FCPL notified the Personal Data Protection Commission (the “Commission”) of the Incident on 12 November 2020, after having received a ransom demand in respect of the Exfiltrated Data. 3. Sometime in early September 2020, as part of its management of the Website, FCPL extracted the personal data of the Affected Individuals from the database of the Website into an excel file. An FCPL employee who was assigned to work with the excel file failed to protect the file with a password or encrypt it as required by FCPL’s IT policy. Moreover, the employee incorrectly stored the excel file in a publicly accessible online storage bucket, as opposed to the correct, secured storage bucket. These lapses were believed to have led to the Incident. 4. Pursuant to section 53(1) of the PDPA, FCPL is liable for acts done by employees. The question therefore becomes whether FCPL had taken reasonable steps to prevent or detect mistakes such as the one made by the employee. The investigations did not surface any arrangements to supervise or verify its employees’ compliance with its internal policies or detect non-compliance. The Deputy Commissioner for Personal Data Protection therefore found that FCPL had breached the Protection Obligation under section 24 of the Personal Data Protection Act 2012 (the “PDPA”) in respect of the Exfiltrated Data. 5. As the data controller and owner of the Website, ACCA owed the Protection Obligation in respect of the Exfiltrated Data as well. The Deputy Commissioner is satisfied that ACCA discharged this obligation by (i) carrying out a due diligence assessment of FCPL’s data protection policies and practices before their engagement, and (ii) by stipulating data protection requirements in its contract when engaging with FCPL. 6. Taking into account the circumstances of the case, and in particular the factors below, the Deputy Commissioner for Personal Data Protection found ACCA not in breach of the PDPA and decided to issue a Warning to FCPL: a. The number of the Affected Individuals was low; b. The Exfiltrated Data was of a low sensitivity; c. FCPL took immediate remedial actions to prevent the occurrence of a similar incident; and d. FCPL voluntary notified the Commission of the Incident. 7. In view of the remedial actions taken by FCPL, no directions were issued. ",Warning,816c141c71713a45a7d40c205c4815198b33af42,"[""tags"",""decision"",""pdf-url"",""description"",""date"",""timestamp"",""url"",""title"",""nature"",""pdf-content""]" 2023-10-01T11:02:10+08:00,fbd32491db44d3d0c97aa12a99cefd61ec954264,65,65,1,1016,A warning was issued to St. Joseph's Institution International for failing to put in place reasonable security arrangements to protect the personal data in its possession. The incident resulted in the personal data being at risk of unauthorised access.,"[""Protection"", ""Warning"", ""Education"", ""Google Chrome Extension"", ""Virus""]",2021-04-15,https://www.pdpc.gov.sg/-/media/Files/PDPC/PDF-Files/Commissions-Decisions/Decision--St-Josephs-Institution-International-Ltd--12032021.pdf,Protection,Breach of the Protection Obligation by St. Joseph's Institution International,https://www.pdpc.gov.sg/all-commissions-decisions/2021/04/breach-of-the-protection-obligation-by-st-josephs-institution-international,2021-04-15,"PERSONAL DATA PROTECTION COMMISSION Case No. DP-2010-B7196 In the matter of an investigation under section 50(1) of the Personal Data Protection Act 2012 And St. Joseph’s Institution International Ltd. SUMMARY OF THE DECISION 1. On 16 October 2020, St Joseph’s Institution International Ltd. (the “Organisation”) informed the Personal Data Protection Commission that a file listing the personal data of 3155 parents and students (“the File”) was found on a website called VirusTotal (the “Incident”). 2. The Incident occurred on or around 13 October 2020 when a staff of the Organisation downloaded and deployed a Google Chrome browser extension developed by VirusTotal for additional security scanning. Unknown to the staff, apart from security scanning, the extension also forwarded scanned samples to premium members of VirusTotal (the “3rd Parties”) for security analysis and research. This use of samples was made known in VirusTotal’s privacy policy covering the use of the extension. 3. As a result of the Incident, the personal data of 3155 individuals including both parents and students were put at risk of unauthorised access. The personal data affected included the names of parents and students, parents’ email addresses, students’ date of birth, students’ classes, students’ year and grades. 4. Users of the VirusTotal Chrome extension would have to agree to VirusTotal’s Privacy Policy, which provides that once files are uploaded to the VirusTotal website for scanning, copies of these files will be kept by VirusTotal and shared with their subscribers for research purposes. The risk of such file sharing and in turn disclosure of personal data to 3rd Parties ought to have been known to the said staff of the Organisation, but was overlooked due to oversight. Such oversight could have been prevented if the Organisation had sufficiently robust processes for assessing such risks prior to deploying downloaded software, including Chrome Extensions. However, the Organisation lacked such processes. 5. Nevertheless, the Organisation took prompt action to mitigate the effects of the breach by contacting VirusTotal immediately to remove the File and notified all affected individuals. While personal data was disclosed, it was limited to premium members of VirusTotal for research purposes only. 6. On the facts, the Deputy Commissioner for Personal Data Protection found the Organisation in breach of the Protection Obligation under section 24 of the Personal Data Protection Act 2012. However, in consideration of the limited risk of personal data being disclosed, and the Organisation’s commitment to improve its processes, a Warning was issued to the Organisation. 7. The Commission reminds all organisations that they must have sufficiently robust processes to obtain a functional understanding of software to be deployed, in order to assess the security risks to personal data in their possession or control. Failure to do so would be breach of the Protection Obligation. ",Warning,8c090a898191be97b97f6c86d047026a0a44edff,"[""tags"",""decision"",""pdf-url"",""description"",""date"",""timestamp"",""url"",""title"",""nature"",""pdf-content""]" 2023-10-01T11:02:10+08:00,fbd32491db44d3d0c97aa12a99cefd61ec954264,66,66,1,1016,"Chapel of Christ the Redeemer failed to put in place reasonable measures to protect its members' personal data. Further, it did not have written policies and practices necessary to comply with the PDPA.","[""Accountability"", ""Protection"", ""Directions"", ""Others"", ""No Policy"", ""Access control"", ""Indexing""]",2021-04-15,https://www.pdpc.gov.sg/-/media/Files/PDPC/PDF-Files/Commissions-Decisions/Decision---Chapel-of-Christ-the-Redeemer---290121.pdf,"Accountability, Protection",Breach of the Protection and Accountability Obligations by Chapel of Christ the Redeemer,https://www.pdpc.gov.sg/all-commissions-decisions/2021/04/breach-of-the-protection-and-accountability-obligations-by-chapel-of-christ-the-redeemer,2021-04-15,"PERSONAL DATA PROTECTION COMMISSION Case No. DP-2010-B7132 In the matter of an investigation under section 50(1) of the Personal Data Protection Act 2012 And Chapel of Christ the Redeemer SUMMARY OF THE DECISION 1. On 6 October 2020, Chapel of Christ the Redeemer (the “Organisation”) informed the Personal Data Protection Commission (the “Commission”) that a file (the “File”) containing personal data of 815 members’ name, NRIC, address, date of birth, marital status, email address, mobile and residential phone number was inadvertently disclosed online. 2. Investigations revealed that a staff had accidentally uploaded the File (which was supposed to be an internal document) onto the sub-directory on 24 November 2019. The Organisation only discovered the matter on 8 September 2020 when a member of the Organisation performed a Google search of another member’s name and found a Google search result of the File. 3. The Organisation admitted that there were no access controls to the sub-directory prior to the incident as the sub-directory was intended to be accessible to public. As a result, the File was indexed by search engines and showed up in online search results. The Organisation also admitted that at the time of the incident, the Organisation had not developed any internal policies and practices to ensure compliance with the Personal Data Protection Act 2012 (the “PDPA”). In particular, there was no system of checks for the uploading of files on the Organisation’s website. 4. Fortuitously, it appeared that the access to the File was minimal – based on Google Analytics Report, save for the Organisation’s member who discovered the File on the internet on 8 September 2020, there was only one other access to the File on 9 December 2019, and the access only lasted for approximately 1 minute. 5. Following the incident, the Organisation disabled the search engine indexing to the subdirectory, password-protected all files with members’ data, and implemented a weekly check of all files uploaded onto the website to detect any accidental uploading of incorrect files; and a policy to delete files that are on the website for more than three months. The Organisation has also informed the Commission that it intends to engage a consultant to conduct PDPA training for its staff, as well as to review the data protection processes within the Organisation to ensure compliance with the PDPA. 6. In view of the facts stated at [3] above, the Deputy Commissioner for Personal Data Protection found the Organisation in breach of section 12 of the PDPA (the obligation to develop and implement data protection policies and practices), and section 24 of the PDPA (the obligation to protect personal data in an organisation’s possession or under its control by making reasonable security arrangements). 7. In determining the directions to be imposed on the Organisation under section 29 of the PDPA, the following factors were taken into account: (a) The Organisations had voluntarily notified the Commission of the incident, fully cooperated with the Commission’s investigations and implemented prompt remedial measures to address the breach; and (b) There was minimal access to the File and no evidence that the personal data had been misused. 8. In the circumstances, the Deputy Commissioner would not be imposing any financial penalty on the Organisation. However, in light of the Organisation’s lack of the necessary data protection policies and practices, the Deputy Commissioner hereby directs the Organisation to: (a) Develop and implement internal data protection policies and practices to comply with the provisions of the Act within 90 days from the date of the direction, and (b) Inform the Commission within 1 week of implementation of the above. ",Directions,3af9997c53409121b23cd38f9ec106f784e3648c,"[""tags"",""decision"",""pdf-url"",""description"",""date"",""timestamp"",""url"",""title"",""nature"",""pdf-content""]" 2023-10-01T11:02:10+08:00,fbd32491db44d3d0c97aa12a99cefd61ec954264,67,67,1,1016,"A financial penalty of $29,000 was imposed on Tripartite Alliance for failing to put in place reasonable security arrangements to prevent the unauthorised access of approximately 20,000 individuals’ and companies’ data stored in its customer relationship system database.","[""Protection"", ""Financial Penalty"", ""Social Service"", ""Ransomware"", ""Scope of Duties"", ""Third Party Vendor""]",2021-04-15,https://www.pdpc.gov.sg/-/media/Files/PDPC/PDF-Files/Commissions-Decisions/Decision---Tripartite-Alliance-Limited---16032021.pdf,Protection,Breach of the Protection Obligation by Tripartite Alliance,https://www.pdpc.gov.sg/all-commissions-decisions/2021/04/breach-of-the-protection-obligation-by-tripartite-alliance,2021-04-15,"PERSONAL DATA PROTECTION COMMISSION Case No. DP-2003-B6000 In the matter of an investigation under section 50(1) of the Personal Data Protection Act 2012 And Tripartite Alliance Limited SUMMARY OF THE DECISION 1. On 3 March 2020, Tripartite Alliance Limited (the “Organisation”) notified the Personal Data Protection Commission (the “Commission”) that a server hosting its customer relationship management (“CRM”) system was infected with ransomware on or around 17 February 2020. 2. The Organisation subsequently requested 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 set out in this decision. It also admitted that it was in breach of section 24 of the Personal Data Protection Act (the “PDPA”). The Incident 3. The Organisation is in the business of promoting fair and progressive employment practices, as well as providing mediation and advice in employment–related disputes. 1 4. The CRM system is a Software-as-a-Service (“SaaS”) solution provided by a software service provider engaged by the Organisation (the “Vendor”). The Organisation uses the CRM system to handle employment-related enquiries, feedback and complaints. 5. At the time of the incident, the CRM system contained approximately 12,000 individuals’ and 8,000 companies’ data (including information of the companies’ representatives). The types of data affected for each individual varied, but may include an individual’s name, identification number, contact number, email address, age, race, marital status, salary and compensation amount (if applicable). 6. On 17 February 2020, the CRM system was unavailable to users. The Vendor managed to restore the CRM system from a back-up copy within the next three hours. 7. Upon investigations, the Organisation determined that the CRM system suffered a ransomware attack. In particular, security logs obtained from the Vendor showed that hacking attempts were made on the database server between 7 and 14 February 2020. 8. The Organisation claimed that it had, since June 2019, expanded the scope of the IT services procured from the Vendor to include security monitoring services for the CRM system, such as the blocking of cyber-attacks based on alerts. However, there was inadequate process put in place to ensure that the Vendor proactively monitor the alerts and take actions to block malicious activities in a timely manner. Nevertheless, the 2 Organisation accepts that it had the responsibility to ensure that the Vendor had the same understanding on its duty of care under the monitoring services contract and to oversee and supervise the work of the Vendor through clear instructions on regular reporting and updates by the Vendor. 9. Following the incident, the Organisation started close monitoring of the Vendor’s IT services support on a weekly basis to ensure timely update of patches and follow-ups on security alerts received. The Organisation also undertook an organisation-wide review to strengthen its management of all its third-party IT service providers, such as requesting these service providers to conduct cybersecurity audits, vulnerability assessment and penetration testing for the Organisation’s existing IT systems. The Organisation also informed the Commission that it will be migrating to a new CRM system and is currently working to terminate the existing CRM system. 10. The Organisation informed the Commission that the database in the CRM system was not protected by encryption at the time of the incident, which made the database vulnerable for exposure. However, there was no evidence that the hacker had exfiltrated the database. The Organisation’s Admission and the Commission’s Decision 11. The Organisation admitted that it had breached the Protection Obligation under section 24 of the PDPA in failing to ensure that the Vendor had duly discharged its contractual data protection obligations. In particular, the Organisation admitted that it had not 3 monitored the Vendor’s performance to ensure that the Vendor met the required information security standards. 12. As stated in previous decisions by the Commission1, organisations have to give proper instructions and exercise reasonable oversight over their vendors to ensure that their outsourced providers are indeed delivering the services contracted. Without reasonable oversight, the risk from any failure will fall on the organisation. In the circumstances, the Commissioner found that the Organisation was in breach of the Protection Obligation under section 24 of the PDPA. 13. As for the Vendor, it was a SaaS provider who provided the CRM system, including maintenance support, and security monitoring services. These services did not entail the processing of personal data. As such, the Vendor was not a “data intermediary” of the Organisation. Accordingly, the Vendor was not responsible for the protection of the individuals’ personal data under the PDPA in respect of the incident. 14. In determining the directions to be imposed on the Organisation for the breach, the Commissioner took into account the following factors: 1 See for example, Re Smiling Orchid (S) Pte Ltd and Ors [2016] SGPDPC 19, Re Royal Caribbean Cruises (Asia) Pte Ltd [2020] SGPDPC 5, and Re SCAL Academy Pte. Ltd. [2020] SGPDPC 2. 4 Aggravating (a) The high number of affected individuals, which is approximately 20,000; (b) The nature of the affected data. In particular, the database contained details of employment-related complaints and disputes. Individuals would expect a high level of confidence when they convey such matters to the Organisation for handling; Mitigating (c) The Organisation’s upfront admission of breach of the Protection Obligation, and the prompt remedial actions to mitigate the effects and prevent recurrence of the incident; and (d) There was no evidence of exfiltration of the database in the CRM system. 15. On account of the above, the Organisation is directed to pay a financial penalty of $29,000 within 30 days from the date of this direction. In view of the remedial action of the Organisation, the Commission will not be issuing any other directions. 5 ",Financial Penalty,0cdce22d84405d3787ba0a1ff0507d00cb8cec7f,"[""tags"",""decision"",""pdf-url"",""description"",""date"",""timestamp"",""url"",""title"",""nature"",""pdf-content""]" 2023-10-01T11:02:10+08:00,fbd32491db44d3d0c97aa12a99cefd61ec954264,68,68,1,1016,"Jigyasa was found in breach of the PDPA. First, Jigyasa failed to put in place reasonable measures to protect employee assessment reports on its website. Second, it did not appoint a data protection officer. Lastly, it did not have written policies and practices necessary to ensure its compliance with the PDPA. An application for reconsideration was filed against the decision in Re Jigyasa [2020] SGPDPC 9. Upon review and careful consideration of the application, directions in the decision were varied in the Reconsideration Decision and a financial penalty of $30,000 was imposed on Jigyasa.","[""Accountability"", ""Protection"", ""Financial Penalty"", ""Professional"", ""Scientific and Technical"", ""No Policy"", ""No DPO"", ""Public access"", ""No pre-launch testing""]",2021-03-11,https://www.pdpc.gov.sg/-/media/Files/PDPC/PDF-Files/Commissions-Decisions/Decision---Jigyasa---30032020.pdf,"Accountability, Protection",Breach of the Protection and Accountability Obligations by Jigyasa,https://www.pdpc.gov.sg/all-commissions-decisions/2021/03/breach-of-the-protection-and-accountability-obligations-by-jigyasa,2021-03-11,"PERSONAL DATA PROTECTION COMMISSION [2020] SGPDPC 9 Case No DP-1707-B0922 In the matter of an investigation under section 50(1) of the Personal Data Protection Act 2012 And Jigyasa (UEN: 52948595L) … Organisation DECISION 1 Jigyasa [2020] SGPDPC 9 Tan Kiat How, Commissioner — Case No DP-1707-B0922 30 March 2020 Introduction 1 This case concerns the unauthorised disclosure of employee assessment reports, such as 360 Feedback Reports and evaluation reports (collectively, the “Reports”), on the website (“Website”) of Jigyasa (the “Organisation”), a human resource and management consultancy business. Material Facts 2 The Organisation is a business operated by a sole proprietor with one part-time employee. The Reports were generated based on survey results collected by the Organisation via its web application (the “Web Application”) and stored in a folder on the server which hosted the Web Application. Reports documented 360 degree feedback on employees of the Organisation’s clients, based on evaluation by their subordinates, supervisors and/or peers. The feedback included character qualities, for example whether they were considered fair, honest, reliable and trusted, demonstrated professional behaviour at all times or had good technical knowledge. Each of these character qualities was given an average rating from a scale of 1 to 10, with 9-10 being an exceptional strength and 1-2 being below expectations. These Reports comprehensively set out such information for each named individual employee of the Organisation’s clients. There is also a section which provides verbatim comments from respondents (e.g. “handle more complex responsibilities”, “slower support”). Some of the Reports also included individual employees’ qualities, such as leadership, integrity, decision-making, initiative, and professional disposition, ranked against their colleagues. 2 3 On 10 July 2017, the Personal Data Protection Commission (the “Commission”) received complaints from 3 individuals (the “Complainants”) alleging that when they searched their names on the Internet, the search results included links to copies of their 360 Feedback Reports, and these reports were accessible through the links (the “Incident”). 4 When notifying the Commission, the Complainants stated that they expected these Reports to be private and confidential and that the disclosure of their 360 Degree Feedback Report would have a significant impact on their job prospects and career options. One of the Complainants alleged that as the industry the Complainant worked in is “extremely niche”, “this could be the reason [he has] not been successful in his job interviews over the past 2 years”. No evidence was adduced to support such claims. Nevertheless, the possibility that the information contained in the Reports may have been accessed by a prospective employer’s human resource personnel as they conducted due diligence on job applications cannot be discounted. 5 The Organisation did not appear to be familiar with the security arrangements of its Website and was not able to provide clear accounts on what led to the Incident during the course of the investigation. In this regard, it was noted that the Organisation had ceased the use of the Web Application in 2010, some 7 years before the Commission’s investigation. The Organisation initially claimed that it did not know that when a client requested for a 360 Feedback Report using the Web Application, a copy of the Report would be saved on the Organisation’s system as a PDF file. It claimed that the Report was dynamically generated by the Web Application and presented for viewing, without storing a copy on the Website. However, when the operation of the Web Application was demonstrated to it, the Organisation agreed that the Reports could have been created but disclaimed knowledge of this. It also maintained that the data should have been removed from the server when that particular version of the Web Application was discontinued in 2010. In this regard, the Organisation’s explanation was that “[the Web Application] and all its data should have been removed, but I am not sure if [the Web Application] is still in the server”. 3 6 In relation to how the Reports became publicly accessible, the Organisation’s version of events is that the webpages containing the Reports (the “Webpages”) were inadvertently created on or around February 2017 during the redesign of the Organisation’s Website. The Organisation had engaged an independent developer (the “Developer”) to redesign its Website by changing it from HTML to WordPress. The Developer provided a test URL to the Organisation to confirm that the Website was designed according to the latter’s instructions. The Organisation did so, but did not detect that the Webpages had been created. According to the Organisation, during the redesign process, password protection for the Reports was not implemented even though this was implemented previously. On balance, the Organisation is given the benefit of doubt and its position that the Reports were made publicly accessible as a result of the redesign is accepted. The complaint to the Commission (on 10 July 2017), was submitted not long after the redesigning of the Website in or around February 2017, and to the Commission’s knowledge, there had not been any complaints prior to this. If the earlier version of the Website did not implement any form of access control, any one of the employees of the Organisation’s clients who had used the system would likely have raised this as an issue and the Organisation would have had to rectify it. 7 At the time of the Incident, the webpages contained Reports relating to 671 employees of the Organisation’s clients (the “Affected Individuals”). Depending on the type of Report, the information therein (collectively, “Personal Data”) may have included: (a) the names of the Affected Individuals; (b) the name and addresses of the Affected Individuals’ employers; (c) appraisals of the Affected Individuals’ work performance by subordinates, supervisors and/or peers; (d) the Affected Individuals’ 360 Feedback scores; and (e) an indication of whether the Affected Individuals were top performers within their respective organisations. 4 Remedial Measures 8 Upon being notified of the Incident by the Commission, the Organisation undertook the following remedial actions: (a) moved the Reports to password-protected locations and subsequently deleted Reports prepared for former clients; (b) requested the service provider hosting the Website (the “Webhost”) to provide the Organisation with the access logs for the Webpages; (c) engaged a developer to scan the Website and find out whether there were more webpages containing Reports which were accessible through the Internet without any access restrictions; and (d) requested the Webhost to conduct an audit of all web based applications and introduce enhanced security monitoring to prevent any lapses. Findings and Basis for Determination Whether the Organisation had breached section 24 of the PDPA 9 Section 24 of the Personal Data Protection Act 2012 (“PDPA”) requires organisations to protect personal data in their possession or under their control by making reasonable security arrangements to prevent unauthorised access, collection, use, disclosure, copying, modification, disposal or similar risks. Although the Organisation had engaged the Developer to redesign the Website, the Developer did not process any personal data on behalf of the Organisation. The Organisation managed the Website on its own and retained full responsibility for the IT security of the Website and the Personal Data. 10 First, as stated in paragraph 5 above, the Organisation demonstrated a lack of knowledge as to the security arrangements of its Website, in particular, the creation and storage of the Reports, and had been under the mistaken impression that the Personal Data had been removed from the server when the previous Website was discontinued. In order to fulfil its Protection Obligation, the Organisation is required to, at the very 5 least, be aware of how and where it stores personal data in order to implement measures to protect such data. In this regard, the Guide on Building Websites for SMEs (revised 10 July 2018) states that: “5.7 Personal Data Inventory 5.7.1 Organisations and any engaged IT vendors should keep track of where the collected personal data is stored, and should impose a limit on how long the data is kept, or regularly review their need to continue storing the personal data. 5.7.2 If the personal data is no longer required, organisations and any engaged IT vendors should then ensure that the personal data is anonymised or disposed of in such a way that it cannot be recovered.” [Emphasis added.] 11 Secondly, the Organisation did not give any specific instructions to the Developer to protect personal data or on security arrangements of its Website during the redesign process. The engagement was done over a short email exchange, and the Organisation could not produce the contract or evidence of any written instructions to the Developer on security arrangements. It had relied solely on the goodwill and integrity of the Developer to conduct the redesign properly, without any documentation, supervision or other means of control. 12 While the Organisation claimed that the Developer was engaged to merely change the “look and feel” of the Website, the facts suggest that the redesign of the Website was a more involved project which required a significant amount of coding work and amounted to building a new Website. In this regard, the Developer had expressly informed the Organisation that the scope of work involved the need to redesign the Website on the WordPress environment instead of using the HTML coding of the existing Website and required the existing content on the Website to be migrated. This is not merely a redesign of the look-and-feel of the Website, but a redevelopment. Thus, the Organisation should have provided the Developer with clear instructions to ensure that no personal data was subject to unauthorised disclosure or access as a result of the redesign. 6 13 According to the Guide on Building Websites for SMEs (at [4.2]): “4.2.1 Organisations should emphasise the need for personal data protection to their IT vendors, by making it part of their contractual terms. The contract should also state clearly the responsibilities of the IT vendor with respect to the PDPA. When discussing the scope of the outsourced work, organisations should consider whether the IT vendor’s scope of work will include any of the following:  Requiring that IT vendors consider how the personal data should be handled as part of the design and layout of the website.  Planning and developing the website in a way that ensures that it does not contain any web application vulnerabilities that could expose the personal data of individuals collected, stored or accessed via the website through the Internet. …” [Emphasis added.] 14 The Commission has also taken a similar position in Re Tutor City [2019] SGPDPC 5, in which the organisation was unaware of its obligations under the PDPA and showed a lack of knowledge of the security arrangements over its website. Specifically, the organisation in that case did not, inter alia, communicate any specific security requirements to its developer to protect the personal data stored on the website’s server (including ensuring that the personal data would not be accessible to the public). 15 Thirdly, the Organisation failed to conduct vulnerability scans or any other form of security testing for the Website. As set out in the Guide on Building Websites for SMEs (at [5.6]): “5.6 Security Testing 5.6.1 Testing the website for security vulnerabilities is an important aspect of ensuring the security of the website. Penetration testing or vulnerability assessments should be conducted prior to making the website accessible to the public, as well as on a periodical basis (e.g. annually). Any discovered vulnerabilities should be reviewed and promptly fixed to prevent data breaches. 7 5.6.2 Where organisations have outsourced the development of its website, they should either require the IT vendor(s) to conduct the above security testing, or arrange for a cybersecurity vendor to do so. As a baseline, organisations may wish to consider using the Open Web Application Security Project (OWASP) Testing Guide and the OWASP Application Security Verification Standard (ASVS) to verify that security requirements for the website have been met.” [Emphasis added.] 16 In Re InfoCorp Technologies Pte Ltd [2019] SGPDPC 17, the Commission took the view that the organisation’s failure to conduct web application vulnerability scans was a breach of section 24 of the PDPA, and that given the sensitivity of the personal data which the documents contained, it was unreasonable that the organisation had omitted security testing prior to the launch of the website. Also, in Re WTS Automotive Services Pte Ltd [2018] SGPDPC 26, the Commission emphasised the need for regular review of security arrangements and tests to detect vulnerabilities, it stated (at [18]) that: “… [t]he Commission also recognises that personal data of individuals may be exposed if the website or database in which it is stored contains vulnerabilities. There needs to be a regular review to ensure that the website collecting personal data and the electronic database storing the personal data has reasonable security arrangements to prevent unauthorised access, collection, use, disclosure, copying, modification, disposal or similar risks. The Commission considers that it is good practice for an organisation to “conduct regular ICT security audits, scans and tests to detect vulnerabilities…” [Emphasis added.] 17 In this case, even if the Organisation was unaware that the Reports were being created and stored, had the Organisation conducted vulnerability scans as a form of security testing on its Website prior to the redesigned Website going live or at any time after that, the fact that the folders contained Reports with personal data and the fact that the Reports were publicly-accessible would likely have been detected and could have been remedied. As a result, the Organisation was unable to assess whether the folders ought to have been restricted. It also did not consider whether any webpages which were created as part of the redesign of its Website were correctly created. 8 18 The foregoing lapses demonstrate a fundamental lack of care by the Organisation over the personal data in its possession and/or under its control. It is clear that the Organisation had not applied its mind to its obligations under section 24 of the PDPA with respect to implementing adequate security arrangements to protect the Reports. In view of the above, the Commissioner found the Organisation in breach of section 24 of the PDPA. Whether the Organisation had breached sections 11(3) and 12 of the PDPA 19 Section 11(3) of the PDPA requires organisations to designate one or more individuals, typically referred to as the data protection officer (“DPO”) to be responsible for ensuring the organisations’ compliance with the PDPA. Section 12 of the PDPA requires organisations to, inter alia, develop and implement policies and practices that are necessary for the organisation to meet its obligations under the PDPA (“Data Protection Policies”), and to communicate information about such policies and practices to its staff. 20 In the course of the Commission’s investigations, the Organisation admitted that it was unaware of the data protection provisions of the PDPA and was under the impression that the PDPA only relates to the Do-Not-Call provisions. Hence, the Organisation did not appoint a DPO or develop and implement any Data Protection Policies. In this regard, it is a trite principle of law that ignorance of the law is no excuse. Hence, the Organisation’s lack of awareness of its obligations under the PDPA is not an excuse for contravening the PDPA. 21 The Organisation also admitted that, at the time of the Incident, it only had certain unwritten policies with respect to the protection of client data, which were communicated to its employees. In this regard, it is important to reiterate that an organisation’s Data Protection Policies should be documented in a written policy, as per Re Furnituremart.sg [2017] SGPDPC 7 at [14]: “[t]he lack of a written policy is a big drawback to the protection of personal data. Without having a policy in writing, employees and staff would not have a reference for the Organisation’s policies and practices which they are to follow in order to protect personal data. Such policies and practices would be ineffective if passed on by word of mouth, and indeed, the 9 Organisation may run the risk of the policies and practices being passed on incorrectly. Having a written policy is conducive to the conduct of internal training, which is a necessary component of an internal data protection programme.” 22 In light of the foregoing, the Commissioner found that the Organisation had also breached sections 11(3) and 12 of the PDPA. Representations by the Organisation 23 In the course of settling this decision, the Organisation made representations on the amount of financial penalty that was to be imposed. The Organisation raised the following factors for consideration: (a) The Commission should not have placed such significant weight on the Personal Data in the Reports that was exposed in the Incident. In this regard, the Personal Data in the Reports should not be accorded the status of sensitive personal data and treated as an aggravating factor because: (i) The Reports did not contain the Affected Individual’s identification/NRIC number, health data or biometric data. The identifying personal data was limited to the name of the Affected Individuals and the name of his/her employer; and (ii) The feedback data in the Reports would not fall within the realm of what would typically be known as sensitive personal data as defined in Articles 9 and 10 of the European General Data Protection Regulation (“GDPR”); (b) Any aggravating weight to be given to the disclosure of the Reports must be reduced by the fact that evaluative purpose exception in the PDPA permits a prospective employer to obtain such feedback or evaluative information without consent of the Affected Individuals. The Organisation posited that the evaluative purpose exception tempers the extent of breach or application of the Protection Obligation because disclosure is permitted so long as the exception applies; (c) The possibility of a member of the public specifically carrying out keyword searches of the names of Affected Individuals during the period when the specific URL links leading to the Reports had been exposed would not be high; 10 (d) The Reports were not more recent than the year 2010. As the Incident occurred in 2017, the accuracy of the contents of the Reports would have waned with the effluxion of time, and this could be a point taken into consideration by a prospective employer; (e) In past decisions, the Commission has taken into consideration the financial circumstances of an organisation in determining the financial penalty (if any) to be imposed. The financial penalty that the Commissioner intended to impose would have a crushing burden on the Organisation, and cause undue hardship. Further, taking into consideration the type of personal data and the potential harm to the Affected Individuals, the proposed financial penalty would be disproportionately higher than what had been imposed on organisations in previous decisions; and (f) The Incident was a one-off occurrence and there was no evidence that the Website was otherwise insecure. During the past 16 over years that the Organisation has been in business, there were no other complaints in relation to unauthorised disclosure of personal data. 24 With respect to the Organisation’s representations on the nature of the Personal Data in the Reports at [23(a)], Singapore’s legislative approach to determining the sensitivity of personal data is different from jurisdictions like the European Union. Unlike the GDPR, the PDPA does not have a definition of sensitive personal data. It is inappropriate to draw comparisons with the GDPR approach to defining sensitivity of personal data as the jurisprudential basis of GDPR is markedly different from the PDPA. The Commission’s approach in each case is to assess the nature of the personal data in question, taking into account specific circumstances such as the context in which the data was collected and the potential risk of harm due to unauthorised access or disclosure. 25 The Organisation’s representations on the evaluative purpose exception at [23(b)] cannot be accepted. The fact that personal data that may be collected, used or disclosed under an exception to consent cannot ipso facto be equated with an inference that the class of personal data is less sensitive and need not be protected, or that there is less culpability for a failure to protect. It is necessary to examine the nature of the exception and the raison d’etre for its existence. The following analysis is confined to the 11 evaluative purpose and is not intended to establish any special rule for personal data covered by other exceptions. (a) The PDPA recognises that there is a class of personal data that exists for an evaluative purpose. A perusal of its definition discloses that the categories of activities are characterised by the need for full disclosure and frank discussions in order to arrive at a decision to, for example, employ, promote or dismiss a person, amongst a list of other circumstances that circumscribe this purpose.1 The recognition of the need for full disclosure and frank discussions is carried through in a number of exceptions, which permit personal data to be collected, used and disclosed without consent. 2 Further, personal data in the nature of opinion data kept solely for an evaluative purpose is exempted from the access and correction requirements. 3 The upshot of these exceptions is to recognise the necessity to preserve the space for full disclosure of relevant personal data and frank exchanges of views between persons who are tasked to conduct an evaluation before making a decision or recommendations leading to a decision. (b) Given the nature of the evaluative purpose exceptions and their raison d’etre, it is necessary to ensure that organisations accord personal data that is covered by the evaluative purpose exceptions with a higher degree of protection. The quid pro quo for organisations having the liberty to collect, use and disclose personal data without consent for evaluative purposes, and to keep opinion data beyond the reach of data subjects for access and correction, is that they are expected to put in place more robust measures to comply with the Protection Obligation. In other words, personal data that is kept for an evaluative purpose should be treated as sensitive data and be protected to a greater degree. See definition of “evaluative purpose” in section 2 of the PDPA. See also Section 29(3) of New Zealand’s Privacy Act 1993 which has a similar definition of “evaluative material” for the purposes of a refusal to disclose personal information pursuant to Principle 6 (Access to personal information). 2 See para 1(f) of the Second Schedule, para 1(f) of the Third Schedule and para 1(h) of the Fourth Schedule of the PDPA. 3 See para 1(a) of the Fifth Schedule and para 1(a) of the Sixth Schedule of the PDPA respectively. See also Section 29(1)(b) of New Zealand’s Privacy Act 1993 which permits an agency to refuse to disclose personal information pursuant to Principle 6 if (i) the disclosure of the information or of information identifying the person who supplied it, being evaluative material, would breach an express or implied promise (i) which was made to the person who supplied the information; and (ii) which was to the effect that the information or the identity of the person who supplied it or both would be held in confidence. 1 12 (c) Further, the Incident in the present case involved the risk of unauthorised disclosure to the world at large whereas the evaluative purpose exception is much narrower in scope (i.e. it permits disclosure of personal data without consent to specific individual(s)/organisation(s) only where it is necessary for evaluative purposes). The expectations of persons who provided the 360-degree feedback would have been for their feedback to be accessed by persons with a role in evaluating the performance of the employee under review. It would be difficult, by any stretch of imagination, for them to accept that their feedback was accessible by the world at large. 26 The possibility of actual unauthorised disclosure raised by the Organisation at [23(c)] had already been taken into consideration in determining the financial penalty that was to be imposed. While the risk of actual unauthorised disclosure may have not been high, the fact that the Reports were exposed to the risk of unauthorised access and disclosure for more than 7 years (between 2009 to 2017) is particularly glaring. 27 As for the accuracy of the contents of the Reports at [23(d)], the passage of approximately 7 years is unlikely to make a significant difference to the potential harm suffered by the Affected Individuals due to unauthorised access or disclosure of the Reports, or dampen the expectations of the persons who provided feedback as discussed in [25(c)]. 28 With respect to the Organisation’s representations comparing the present case to earlier decisions at [23(e)], it needs only be said that each decision is based on the unique facts of that case. The decision in each case takes into consideration the specific facts of the case so as to ensure that the decision and direction(s) are fair and appropriate for that particular organisation. 29 The fact that the Incident may have been the Organisation’s first data breach is not a mitigating factor. Conversely, if the Incident was a repeated contravention by the Organisation of the Protection Obligation, this would likely weigh in favour of a higher financial penalty. 30 Having carefully considered the representations, the Commissioner has decided to reduce the financial penalty to the amount set out at [33(a)]. The quantum of financial penalty has been determined after due consideration of the appropriate weight to be 13 given to the aggravating factors at [32], the Organisation’s financial circumstances and to avoid imposing a crushing burden on the Organisation. Although a lower financial penalty has been imposed in this case, this is exceptional and should not be taken as setting any precedent for future cases. The Commissioner’s Directions 31 In determining the directions to be imposed on the Organisation under section 29 of the PDPA, the Commissioner took into account, as a mitigating factor, the fact that the Organisation had promptly taken the remedial measures set out above (at [8]). 32 The Commissioner also took into account the following aggravating factors: (a) the Personal Data in the Reports were sensitive in nature as they included data on the assessment of the Affected Individuals’ work performance and unauthorised access of such data could potentially result in harm to the individuals concerned (for example, the individuals’ future employment prospects may be affected); (b) the Personal Data in the Reports was exposed to the risk of unauthorised access and disclosure for a period of more than 7 years; and (c) the Organisation showed a lack of awareness of its obligations under the PDPA even though it processes large volumes of sensitive personal data in the course of its business. 33 Having carefully considered the facts and circumstances of this case and the above mitigating and aggravating, the Commissioner hereby directs the Organisation: (a) To pay a financial penalty of $90,000 within 30 days of the date of this direction, failing which interest at the rate specified in the Rules of Court in respect of judgment debts shall accrue and be payable on the outstanding amount of such financial penalty until the financial penalty is paid in full; (b) to appoint a DPO within 30 days from the date of this direction; and 14 (c) to develop and implement policies and practices that are necessary for the Organisation to meet its obligations under the PDPA, and communicate them to its staff, within 30 days of the date of this direction. YEONG ZEE KIN DEPUTY COMMISSIONER FOR COMMISSIONER FOR PERSONAL DATA PROTECTION 15 ",Financial Penalty,6a21009555c09878fe1f590900953bc8f01d5acf,"[""tags"",""decision"",""pdf-url"",""description"",""date"",""timestamp"",""url"",""title"",""nature"",""pdf-content""]" 2023-10-01T11:02:10+08:00,fbd32491db44d3d0c97aa12a99cefd61ec954264,69,69,1,1016,"A financial penalty of $9,000 was imposed on Iapps for failing to put in place reasonable security arrangements to prevent the unauthorised disclosure of personal data of some users of the ActiveSG mobile application.","[""Protection"", ""Financial Penalty"", ""Information and Communications"", ""Code deployment"", ""Wrong Environment""]",2021-03-11,https://www.pdpc.gov.sg/-/media/Files/PDPC/PDF-Files/Commissions-Decisions/Decision---Iapps-Pte-Ltd---10022021.pdf,Protection,Breach of the Protection Obligation by Iapps,https://www.pdpc.gov.sg/all-commissions-decisions/2021/03/breach-of-the-protection-obligation-by-iapps,2021-03-11,"PERSONAL DATA PROTECTION COMMISSION [2021] SGPDPC 1 Case No DP-1903-B3441 In the matter of an investigation under section 50(1) of the Personal Data Protection Act 2012 And Iapps Pte Ltd. … Organisation DECISION Iapps Pte Ltd [2021] SGPDPC 1 Lew Chuen Hong, Commissioner — Case No DP-1903-B3441 10 February 2021 Introduction 1 On 1 March 2019, the Personal Data Protection Commission (the “Commission”) received a complaint from an individual (the “Complainant”) in relation to potential unauthorised disclosure of his personal data through the ActiveSG mobile application (the “ActiveSG App”). The Complainant’s concerns arose because he was able to view another individual’s personal data when he logged into his child’s supplementary account on the ActiveSG App (the “Incident”) Facts of the Case 2 ActiveSG is a national movement for sports coordinated by Sport Singapore,1 a statutory board of the Ministry of Culture, Community and Youth. Iapps Pte Ltd (the “Organisation”) is a financial technology company specialising in mobile application development and marketing. Sport Singapore engaged the Organisation to develop, deploy and operate the Super Sports Club Membership Management System (“SSCMMS”). The functions of SSCMMS included membership registration, and the ActiveSG App was a component of 1 Sport Singapore was formerly known as Singapore Sports Council. Iapps Pte Ltd [2020] SGPDPC 1 the SSCMMS. Members of ActiveSG could use the ActiveSG App to book sport facilities, register for fitness classes and purchase entry passes to ActiveSG sport centres. 3 Sport Singapore is the owner of the SSCMMS and ActiveSG App. Pursuant to the written contract between the Organisation and Sport Singapore, the Organisation’s scope of work included providing and operating the production server for the ActiveSG app. The Organisation also developed, deployed and operated the SSCMMS (including the ActiveSG App). 4 On 1 March 2019, the Organisation’s engineer developed a security code fix for the ActiveSG App. The security code fix was meant to be deployed into the enterprise environment (which was a test environment) for further testing. However, due to human error, the security code fix was deployed into the production environment, resulting in the Incident. 5 According to the Organisation, the personal data of 153 individuals (the “At Risk Individuals”) had been at risk of unauthorised access by 84 individuals during the Incident. Out of the At Risk Individuals, there was actual unauthorised access of 108 individuals’ (including 9 minors below the age of 18) (the “Affected Individuals”) names and NRIC numbers (“Disclosed Data”) by 84 individuals who were able to view this information when logging into their own accounts on the ActiveSG App. For 6 of the Affected Individuals, in addition to the Disclosed Data, there was also actual unauthorised access of additional personal data, including (collectively, the “Additional Disclosed Data”): (a) Email address; (b) Mobile telephone number; 2 Iapps Pte Ltd 6 [2020] SGPDPC 1 (c) Home telephone number; (d) Address; (e) Gender; (f) Date of birth; (g) Race; (h) Employment status; and (i) Sports Interests. Upon being notified of the Incident on the same day, the Organisation immediately took the following remedial actions: (a) Rectified the issue within 2 hours of the Incident; (b) Reminded its staff to be careful and vigilant in the course of their work; and (c) Together with Sport Singapore, implemented the following measures: (i) Separated the enterprise environment and production environment that were previously on the same server; (ii) Put in place 2-factor authentication for the Organisation’s engineers to access the production environment. This means that the engineers are required to obtain the 2-factor one-time password from Sport Singapore to access the production environment; 3 Iapps Pte Ltd [2020] SGPDPC 1 (iii) Monitoring of affected users for suspicious activities; and (iv) 7 Implemented dynamic QR codes for member IDs. Sport Singapore also notified the Affected Individuals about the Incident. The Commissioner’s Findings and Basis for Determination 8 There is the preliminary issue of whether the Organisation was a data intermediary for Sport Singapore, and whether it could avail itself of the exception under the previous section 4(1)(c) of the of the Personal Data Protection Act 2012 (“PDPA”).2 9 Effective 1 February 2021, the exclusion in section 4(1)(c) of the PDPA has been amended to be limited to “public agencies” only. Organisations acting on behalf of public agencies in relation to the collection, use or disclosure of public data (even when in an agency relationship of the type described below), are now subject to obligations under the PDPA, and cannot claim to be excluded from the same. 10 As the Incident in this case occurred prior to 1 February 2021, the applicability of the exclusion under the previous section 4(1)(c) of the PDPA remains to be considered. However, the Commission makes clear that this exclusion will not be applicable or considered in future cases. Prior to 1 February 2021, section 4(1)(c) of the PDPA provided that “any public agency or an organisation in the course of acting on behalf of a public agency in relation to the collection, use or disclosure of personal data is not subject to the obligations under Parts III to VI of the PDPA” 2 4 Iapps Pte Ltd 11 [2020] SGPDPC 1 The exclusion in the previous section 4(1)(c) of the PDPA for organisations acting on behalf of public agencies was based on the legal concept of agency i.e. where the organisation was authorised by a public agency to act in its place, as its agent, and the agent manifested assent or otherwise consented to so act.3 Whether an agency relationship was created in any particular case is essentially a question of fact. Relevant factors to take into consideration when determining whether an agency relationship arose included the communications between the parties and their conduct, as well as the terms of any relevant contract. 12 The underlying question in each case was whether the organisation was authorised to act on behalf of the principal. The authorisation by the principal in an agency relationship is usually made expressly, although it could in some cases be by implication from the conduct or situation of the parties. Where there is such authority, the acts of the agent that are within the scope of the authority are the acts of the principal, which would be legally liable for the acts of its agent.4 13 In the present case, the Commission’s investigations revealed that the Organisation was at all material times an independent third party vendor. There was nothing in the contract between the parties which expressly authorised the Organisation to act on behalf of Sport Singapore. The clauses in the contract pointed to the Organisation being a service provider to Sport Singapore, and not its agent. Further, there was an indemnity clause in the contract which obliged the Organisation to among others, indemnify and keep Sport Singapore fully 3 See Alwie Handoyo v Tjong Very Sumitomo and anor [2013] 4 SLR 308 at [147] 4 See Ong Han Ling and anor v American International Assurance Co Ltd and ors [2018] 5 SLR 549 at [208] 5 Iapps Pte Ltd [2020] SGPDPC 1 indemnified against all actions, claims, demands, losses, expenses arising out of or in connection with the performance of the contract by the Organisation. As explained at [11] – [12], if the Organisation and Sport Singapore were in an agency relationship, acts of the agent (i.e. the Organisation) within the scope of authority would be acts of the principal (i.e. Sport Singapore) who would be legally liable for acts of its agent. An indemnity would therefore not be necessary. The presence of the indemnity clause is evidence that the relationship was not a principal-agent relationship. In addition, Sport Singapore confirmed that it had never appointed the Organisation to act in its place. In the circumstances, the exclusion in the previous section 4(1)(c) of the PDPA did not apply to the Organisation. 14 With respect to whether the Organisation was acting as a data intermediary, the Commission’s investigations found that the Organisation was engaged to carry out activities of “processing” personal data on behalf of Sport Singapore as defined in section 2(1) of the PDPA. As mentioned at [3], the Organisation’s scope of work included developing, deploying and operating the SSCMMS (including the ActiveSG App). In the course of operating the SSCMMS and the ActiveSG App, the Organisation organised and retrieved the Disclosed Data and the Additional Disclosed Data on the behalf of Sport Singapore. In addition, the Organisation also processed service requests (which included enquiries and extraction of information including the Disclosed Data and Additional Disclosed Data) on behalf of Sport Singapore. The Organisation was therefore acting as a data intermediary of Sport Singapore Whether the Organisation had contravened section 24 of the PDPA 15 Section 24 of the PDPA provides that an organisation shall protect personal data in its possession or under its control by making reasonable 6 Iapps Pte Ltd [2020] SGPDPC 1 security arrangements to prevent unauthorised access, collection, use, disclosure, copying, modification or similar risks. 16 The obligation to make reasonable security arrangements does not attach unless an organisation was in possession or control of personal data. In the present case, the Organisation provided the production environment and operated the SSCMMS (including the ActiveSG App). The Organisation therefore had actual possession of the Disclosed Data and Additional Disclosed Data and control of the processing activities that they had contracted to provide. Therefore, prior to the Incident, they were obliged to put in place reasonable security arrangements to protect the Disclosed Data and Additional Disclosed Data. 17 The Commission’s investigations revealed that the Organisation’s processes for the deployment of code into production and test environments were not sufficiently robust to safeguard against risks of deployment of codes into the wrong environment. (a) According to the Organisation, its usual code deployment process went through 3 stages (i) User Acceptance Testing (“UAT”); (ii) “enterprise environment” (i.e. test environment); and (iii) production environment. (b) Due to human error on the part of its engineer, the Organisation’s processes and procedures for the deployment of the security code fix into the ActiveSG App were not followed. After the UAT was completed, the code that was meant to be deployed to the testing environment was instead deployed directly into the production environment. This is a grave and serious error with, as is evident in this case, potentially severe consequences. In this regard, the Commission’s 7 Iapps Pte Ltd [2020] SGPDPC 1 investigations revealed that the Organisation did not have second-level approvals or supervisory checks in its processes for the deployment of codes into the test environment. This meant there was no oversight of the code deployment process nor any supervision of the actions of the Organisation’s engineers after UAT was completed. (c) As stated in the Commission’s previous decisions, relying solely on employees to perform their duties diligently is not a sufficient reasonable security arrangement – organisations should take practical steps to implement its policies and procedures to protect personal data, including identifying areas of high risk that require higher level of approval and adequate supervision.5 In the present case, the deployment of the security code fix into the ActiveSG App could potentially expose the Disclosed Data and the Additional Disclosed Data to security risks. The Organisation should have identified this risk, and implemented a second-level check to ensure that its engineers deployed the codes into the correct environment. Alternatively, the Organisation could have automated its processes by using development operations software that would automate the correct deployment of code. (d) The absence of any second-level checks in the Organisation’s processes for the deployment of codes and lack of any other form of security arrangement to safeguard against risks of deployment of codes into the wrong environment amounted to weak internal work process controls. 5 See Re Aviva Ltd [2017] SGPDPC 14 and Re Marshall Cavendish Education Pte Ltd [2019] SGPDPC 34 8 Iapps Pte Ltd 18 [2020] SGPDPC 1 For the reasons above, the Commissioner found the Organisation in breach of section 24 of the PDPA. 19 After being notified of the Commission’s proposed decision including the proposed financial penalty amount, the Organisation made representations to the Commission suggesting that (i) the Organisation had done the necessary to comply with section 24 of the PDPA, or (ii) that a warning ought to be administered in lieu of the Commission’s proposed financial penalty. The Organisation’s representations were rejected for the following reasons: (a) The Organisation contended that it did have second-level checks for the deployment of code, and referred the Commission to its Standard Operating Procedure (“SOP”) for the SSCMMS. While the SOP did describe multi-level checks at the UAT stage (i.e. the first stage of testing), it not dictate any second-level checks relating to the deployment of code into the enterprise environment, and thereafter production environment (i.e. the second and third stages). In fact, the SOP contained no references to deployment of code in the enterprise environment at all. The Organisation failed to provide any evidence of any second-level checks after UAT and before deployment of the code in production. (b) The Organisation claimed that the Incident was the result of human error which happened “in the rush of the moment” and would not have been prevented by a second level check. The Commission disagrees. For the reasons stated at 17(c) and 17(d) above, the appropriate processes such as a second-level check or automated code deployment via software should have been implemented, and would have prevented the Incident. Such processes are all the more necessary 9 Iapps Pte Ltd [2020] SGPDPC 1 considering the time pressure that engineers often operate under, as appears to have happened in this case. (c) The Organisation highlighted that it had taken prompt remedial actions after discovery of the Incident (listed at [6] above). The Commission accepts that the remedial action taken by the Organisation was timely and sufficient. This has been taken this into consideration in quantifying the financial penalty imposed in this case (as set out below), and in deciding that no further directions need be issued to the Organisation. Financial Penalty 20 In determining whether to impose a financial penalty on the Organisation pursuant to section 48J(1) of the PDPA, and if so, the amount of such financial penalty, the Commissioner took into account the factors listed at section 48(6) of the PDPA, including that: (a) that the Disclosed Data included the NRIC numbers of 9 minors; (b) The Organisation cooperated with the Commission’s investigations; and (c) The Organisation implemented prompt remedial actions (i.e. the issue was fixed within 2 hours of the Incident). 21 On 23 July 2020, the Organisation was given notice of the Commission’s intention to impose a financial penalty of S$11,000 and was invited to make representations. Having considered the Organisation’s representations dated 21 August 2020, 21 October 2020, and 29 October 2020, 10 Iapps Pte Ltd [2020] SGPDPC 1 as well as all the relevant factors of this case, the Commissioner hereby requires the Organisation to: (a) pay a financial penalty of S$9,000 within 30 days from the date of the notice accompanying this decision, failing which interest, at the rate specified in the Rules of Court in respect of judgment debts, shall accrue and be payable on the outstanding amount of the financial penalty until it is paid in full. YEONG ZEE KIN DEPUTY COMMISSIONER FOR COMMISSIONER FOR PERSONAL DATA PROTECTION 11 ",Financial Penalty,254f6fd787bbfaed69d1c08e1395d0e7cc753f16,"[""tags"",""decision"",""pdf-url"",""description"",""date"",""timestamp"",""url"",""title"",""nature"",""pdf-content""]" 2023-10-01T11:02:10+08:00,fbd32491db44d3d0c97aa12a99cefd61ec954264,70,70,1,1016,"A financial penalty of $5,000 was imposed on BLS International Services Singapore for failing to put in place reasonable security arrangements to prevent the unauthorised disclosure of the personal data of individuals who had submitted a booking for an appointment on its website.","[""Protection"", ""Financial Penalty"", ""Information and Communications"", ""Inadequate scoping of testing"", ""URL manipulation""]",2021-01-14,"https://www.pdpc.gov.sg/-/media/Files/PDPC/PDF-Files/Commissions-Decisions/Decision---BLS-International-Services-Singapore-Pte,-d-,-Ltd,-d-,-30112020-(003).pdf",Protection,Breach of the Protection Obligation by BLS International Services Singapore,https://www.pdpc.gov.sg/all-commissions-decisions/2021/01/breach-of-the-protection-obligation-by-bls-international-services-singapore,2021-01-14,"PERSONAL DATA PROTECTION COMMISSION Case No. DP-2007-B6563 In the matter of an investigation under section 50(1) of the Personal Data Protection Act 2012 And BLS International Services Singapore Pte. Ltd. SUMMARY OF THE DECISION 1. BLS International Services Singapore Pte. Ltd. (the “Organisation”) provides government-to-citizen services for the High Commission of India in Singapore, such as visa and consular services. 2. On 7 July 2020, the Personal Data Protection Commission (the “Commission”) received information that the URLs of the printable version of appointment booking confirmation webpages could be manipulated to access other individuals’ personal data (the “Incident”). The personal data comprised the individual’s name, passport number, contact number, email address, type of service request, booking date/time, appointment date/time, and number of booking applications. 3. The Organisation subsequently requested 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 set out in this decision. It also admitted that it was in breach of section 24 of the Personal Dara Protection Act (the “PDPA”). 4. Investigations revealed that on 8 June 2020, which was about a month prior to the Incident, the Organisation had implemented a new booking system for the High Commission of India. Under this new booking system, users who submitted a booking for an appointment at the High Commission of India would be provided with an URL, which led to a printable version of the booking confirmation. In designing the booking system, the Organisation had intended for the URLs to be encrypted. This would have made it more difficult for people to manipulate the URL. However, the encryption was not done properly due to a coding error. Although the Organisation had conducted some testing on the new booking system, the testing was not extensive enough to detect the error. 5. Upon realising the occurrence of the Incident from the Commission on 16 July 2020, the Organisation took immediate action to investigate and subsequently identified the coding error. On the same day, the Organisation made changes to the booking system. It stopped providing users with an URL to a printable version of their booking confirmation. Instead, the booking confirmation would be sent to the user’s email account. 6. The Organisation’s records showed that a total of 3,357 individuals used the new booking system from 8 June 2020 to 16 July 2020. This meant that the personal data of 3,357 individuals was at risk of exposure by URL manipulation. 7. The Deputy Commissioner for Personal Data Protection found that the Organisation was in breach of the Protection Obligation under section 24 of the Personal Data Protection Act 2012 for failing to conduct adequate testing of the booking system before it went “live”. Depending on how the URL encryption was implemented, URL encryption could had been a reasonable security measure for the personal data type the Organisation was collecting. However, because the Organisation had not conducted adequate testing of the booking system before it went “live”, the Organisation did not detect the coding error, thereby resulting in the Incident. 8. After considering the circumstances of the case, including: (i) the Organisation’s upfront voluntary admission of liability which significantly reduced the time and resources required for investigations; and (ii) the Organisation’s prompt remedial actions, the Deputy Commissioner for Personal Data Protection directs that the Organisation pays a financial penalty of $5,000 for the breach. 9. 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. 10. No further directions are required as the Organisation had taken actions to address the gaps in its security arrangements. ",Financial Penalty,258d44ffd944015c9b8f9f9ffd545a6b10bb6fee,"[""tags"",""decision"",""pdf-url"",""description"",""date"",""timestamp"",""url"",""title"",""nature"",""pdf-content""]" 2023-10-01T11:02:10+08:00,fbd32491db44d3d0c97aa12a99cefd61ec954264,71,71,1,1016,"A financial penalty of $9,000 was imposed on The Future of Cooking for failing to put in place reasonable security arrangements to prevent the unauthorised disclosure of its customers’ personal data on its website.","[""Protection"", ""Financial Penalty"", ""Wholesale and Retail Trade"", ""Data Intermediary"", ""Protection"", ""Security""]",2021-01-14,https://www.pdpc.gov.sg/-/media/Files/PDPC/PDF-Files/Commissions-Decisions/Decision---The-Future-of-Cooking-Pte-Ltd-20112020-(003).pdf,Protection,Breach of the Protection Obligation by The Future of Cooking,https://www.pdpc.gov.sg/all-commissions-decisions/2021/01/breach-of-the-protection-obligation-by-the-future-of-cooking,2021-01-14,"PERSONAL DATA PROTECTION COMMISSION Case No. DP-2001-B5620 In the matter of an investigation under section 50(1) of the Personal Data Protection Act 2012 And The Future of Cooking Pte. Ltd. SUMMARY OF THE DECISION 1. The Future of Cooking Pte. Ltd. (the “TFC”) operates an e-commerce website at https://www.thermomix.com.sg (the “Website”), retailing kitchen appliances and accessories. 2. On 3 January 2020, the Personal Data Protection Commission (the “Commission”) received a complaint that a text file (the “File”) containing personal data was accessible via the URL: https://thermomix.com.sg/wp-content/uploads/2019/10/woocommerce-orderexport-1.csv-1.txt. (the “Incident”). 3. The File contained the personal data of 178 unique individuals who had purchased items from the Website. The File was accessible via the URL from 1 October 2019 until 6 January 2020. It contained the following types of personal data (the “Personal Data”): a. Name; b. Email Address; c. Billing Address; d. Shipping Address; e. Customer Notes (e.g. delivery instructions); f. Order information (such as payment status, mode of payment, and transaction ID); g. Product ID of items; h. Quantity of items ordered; and i. Telephone number. The Commission’s Findings No breach by Hachi as a Data Intermediary 4. TFC had engaged Hachi Web Solutions Pte. Ltd. (“Hachi”) to re-design the Website and also perform data backup and migration. Insofar as the data backup and migration activities are concerned, Hachi was TFC’s data intermediary. The cause of the breach, however, did not relate to the data processing activities but to the Website re-design. Therefore, Hachi was not in breach of the Protection Obligation under section 24 of the Personal Data Protection Act 2012 (the “PDPA”) by virtue of its role as a data intermediary. TFC in breach of the Protection Obligation 5. The cause of the data breach may be traced to a WordPress plugin (the “Plugin”) which was installed on the Website. The Plugin contained a bug which caused the File to be generated and uploaded on the Website’s directory folder. Although this was a temporary file, it was accessible to the public via the URL. 6. TFC had used the Website to collect the personal data of individuals. At the time of the Incident, TFC’s database contained personal data of approximately 3,500 individuals. To discharge its Protection Obligation under section 24 of the PDPA, TFC needed to have put in place reasonable security arrangements to protect the personal data collected. 7. In this case, investigations revealed that TFC had failed to discharge its obligations as data controller when engaging Hachi to undertake data processing activities. First, TFC did not specify any requirements for Hachi to implement any data protection measures to be implemented in the Website, whether in its contract with Hachi or other project documentation. Second, TFC did not conduct any pre-launch security testing (such as vulnerability assessments) on the Website. Had security testing been conducted, TFC would have been able to detect the presence of the publicly accessible temporary file, even if it was unaware of the bug in the Plugin that caused it. 8. Once it knew about the Incident, TFC and Hachi removed the Plugin and disabled the public’s access to the relevant directory folder. Hachi also contacted the developers of the Plugin, who acknowledged the existence of the bug and fixed the bug in an updated version. TFC subsequently engaged a vendor to perform penetration testing and other measures to enhance the security of the Website. 9. The Deputy Commissioner found TFC in breach of the Protection Obligation under section 24 of the PDPA. After considering the circumstances of the Incident, including according mitigatory weight to TFC’s cooperation with the Commission during investigations and the remedial action taken by TFC after the Incident, the Deputy Commissioner directs TFC to pay a financial penalty of $9,000 for its breach. 10. TFC 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. 11. No further directions are required as TFC had taken actions to address the gaps in its security arrangements. ",Financial Penalty,7255b9fe4b2433c5774bed593dd6215b52226a70,"[""tags"",""decision"",""pdf-url"",""description"",""date"",""timestamp"",""url"",""title"",""nature"",""pdf-content""]" 2023-10-01T11:02:10+08:00,fbd32491db44d3d0c97aa12a99cefd61ec954264,72,72,1,1016,Singapore Technologies Engineering was found not in breach of the PDPA in relation to the transfer of the personal data of its Singapore-based employees to its subsidiaries based in United States.,"[""Transfer Limitation"", ""Not in Breach"", ""Manufacturing"", ""Ransomware""]",2021-01-14,https://www.pdpc.gov.sg/-/media/Files/PDPC/PDF-Files/Commissions-Decisions/Decision----ST-Engineering-Ltd---16112020.pdf,Transfer Limitation,No Breach of the Transfer Limitation Obligation by Singapore Technologies Engineering,https://www.pdpc.gov.sg/all-commissions-decisions/2021/01/no-breach-of-the-transfer-limitation-obligation-by-singapore-technologies-engineering,2021-01-14,"PERSONAL DATA PROTECTION COMMISSION [2020] SGPDPC 21 Case No. DP-2006-B6426 In the matter of an investigation under section 50(1) of the Personal Data Protection Act 2012 And Singapore Technologies Engineering Limited … Organisation DECISION Singapore Technologies Engineering Limited [2020] SGPDPC 21 Singapore Technologies Engineering Limited [2020] SGPDPC 21 Yeong Zee Kin, Deputy Commissioner — Case No. DP-2006-B6426 16 November 2020 Introduction 1 On 10 June 2020, Singapore Technologies Engineering Limited (the “Organisation”) notified the Personal Data Protection Commission (the “Commission”) that its subsidiary based in the United States of America (“USA”), VT San Antonio Aerospace Inc. (“VT SAA”), had discovered a cybersecurity incident where threat actors gained unauthorised access to VT SAA’s US-based IT network and deployed a ransomware attack (the “Incident”). Facts of the Case 2 The Organisation is a Singapore incorporated company with a network of subsidiaries in Asia, Europe, USA and the Middle East. The ransomware attack was isolated to a limited part of VT SAA’s network, but also affected a few of the Organisation’s subsidiaries based in the USA that were using IT shared services provided by VT SAA. The Organisation’s IT network in Singapore was not compromised during the Incident. However, the following types of personal data belonging to 287 individuals in Singapore (“Affected 1 Singapore Technologies Engineering Limited [2020] SGPDPC 21 Individuals”) were potentially exposed to the risk of unauthorised access (collectively, the “Personal Data Sets”)1: (a) Name; (b) Address; (c) Email address; (d) Telephone number; (e) NRIC number and date of issue; (f) Passport details; (g) Photograph; (h) Date of birth; (i) Citizenship; (j) Country of residence; (k) Place of birth; (l) USA Social Security number; (m) USA visa information; (n) Details regarding government or military service, where applicable; (o) CV information; (p) Foreign identification numbers; (q) Government issued identification (ID) information; 1 This list sets out the personal data types potentially affected in the Incident. Not all of these types of personal data were affected for each Affected Individual, and the type(s) of personal data affected for each Affected Individual varies. The Personal Data Sets of 49 Affected Individuals were assessed to have been “likely exfiltrated”, with the remaining Personal Data Sets were assessed to have been “likely affected, may have been exfiltrated”. 2 Singapore Technologies Engineering Limited [2020] SGPDPC 21 (r) Associated information about minors; and (s) Employee status. 3 In this regard, the Affected Individual’s Personal Data Sets had been transferred from the Organisation (in Singapore) to VT SAA and the Organisation’s other subsidiaries (based in the USA). The purposes of the transfer included making regulatory filings with the USA authorities, secondment or transfers of employment and security clearance in connection with visits to facilities. 4 Upon discovery of the Incident, the Organisation and VT SAA immediately took the following remedial actions: VT SAA (a) Notified the federal law enforcement officials in USA; (b) Immediately disconnected certain systems from the network and retained leading third-party forensic advisors to investigate the Incident; (c) Conducted a rigorous review of the Incident and its systems, including deploying advance tools to remediate the intrusion and to restore the affected systems; (d) Strengthened its overall cybersecurity architecture, including enhanced endpoint security controls, additional network monitoring and other security hardening measures; and (e) Implemented a Security Operations Centre to provide 24/7 monitoring, detection and response capabilities. 3 Singapore Technologies Engineering Limited [2020] SGPDPC 21 The Organisation (f) Reprioritised and accelerated its existing IT harmonisation plan (including the enhancement and hardening of internal controls and external program elements) for all its entities. Findings and Basis for Determination 5 As a preliminary point, the data protection obligations in the Personal Data Protection Act 2012 (“PDPA”) did not apply to VT SAA and the Organisation’s other subsidiaries (based in the USA) with respect to the Incident. This is because they did not carry out any activities in relation to the collection, use or disclosure of the Affected Individual’s Personal Data Sets in Singapore. The Commission will defer to the ongoing investigations by the US federal law enforcement officials into VT SAA and the Organisation’s subsidiaries based in the USA. The Commission’s investigations in the present case focused on whether the Organisation’s transfer of the Affected Individual’s Personal Data Sets from Singapore to the USA met the requirements under the PDPA. The Transfer Limitation Obligation under Section 26 of the PDPA 6 Section 26(1) of the PDPA provides that an organisation shall not transfer any personal data to a country or territory outside Singapore except in accordance with requirements prescribed under the PDPA to ensure that organisations provide a standard of protection to personal data so transferred that is comparable to the protection under the PDPA (the “Transfer Limitation Obligation”). The relevant requirements are prescribed in Part III of the Personal Data Protection Regulations 2014 (“PDPR”). In particular: 4 Singapore Technologies Engineering Limited (a) [2020] SGPDPC 21 Regulation 9(1)(b) of the PDPR requires an organisation that transfers personal data to a country or territory outside of Singapore to take appropriate steps to ensure that the recipient of personal data is bound by legally enforceable obligations (in accordance with Regulation 10) to provide to the transferred personal data a standard of protection that is at least comparable to that under the PDPA; (b) Regulation 10(1)(c) of the PDPR provides that such legally enforceable obligations include, amongst other things, any binding corporate rules in accordance with Regulation 10(3) of the PDPR; and (c) Regulation 10(3) of the PDPR provides that such binding corporate rules must require every recipient of the transferred personal data to provide a standard of protection for the transferred personal data that is comparable to that of the PDPA, and must specify (i) the recipients of the transferred personal data to which the binding corporate rules apply; (ii) the countries and territories to which the personal data may be transferred under the binding corporate rules; and (iii) the rights and obligations provided by the binding corporate rules. Further such binding corporate rules may only be used by recipients that are related to the transferring organisation. Whether the Organisation complied with the Transfer Limitation Obligation 7 The Commission’s investigations revealed that the Organisation had complied with the Transfer Limitation Obligation for the reasons explained below. 8 At the material time, the Organisation had put in place binding corporate rules set out in the St Engineering’s Group Binding Corporate Rules for 5 Singapore Technologies Engineering Limited [2020] SGPDPC 21 Transfers of Personal Data (PDP-04) (“BCRs”), which met the requirements of Regulation 9(1)(b) read together with Regulations 10(1)(c) and 10(3) of the PDPR: (a) The BCRs were applicable to and legally binding upon all of the Organisation’s direct and indirect subsidiaries worldwide (each a “Group Company” and collectively, the “Group”), concerning the transfers (including international transfers) of personal data within the Group; (b) The BCRs specified the countries and territories to which personal data may be transferred (which included the USA); (c) Each Group Company that received transferred personal data was bound by legally enforceable obligations to provide a standard of protection for the personal data transferred that is at least comparable to the protection under the PDPA. In particular: “5.6 The Receiving Company shall protect the transferred 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 other similar risks to the transferred Personal Data. 6.1 Each Group Company warrants and undertakes that it has implemented and maintained appropriate security, technological and organisational measures in accordance with the Group Company’s legal obligations under the PDPA or other applicable Data Protection Laws to protect Personal Data and to prevent unauthorised access, 6 Singapore Technologies Engineering Limited [2020] SGPDPC 21 collection, use, disclosure, copying, modification, disposal or other similar risks to the transferred Personal Data.” (d) Rights and obligations provided by the BCRs are specified. These included the permitted purposes for transfer of personal data, data protection obligations of the receiving company, and protection and security of personal data. The permitted purposes set out in the following clauses in the BCRs included the purposes of transfer of the Affected Individual’s Personal Data Sets at [3] “1. Managing or terminating the employment relationship … … (xvii) Preparing and making travel arrangements for employees’ work or business travel (including visa applications, transport and accommodation arrangements) … … 2. Evaluative purposes … … (iii) Evaluation for secondment / transfer of employment to another entity within the Group / for extension of contract (for contract staff) / termination / redundancy / restructuring … … 3. Group’s business operations, including the Group’s internal business management, administration and operations: … … (vi) Submission to government agencies and authorities for permits and approvals … … (xiii) To facilitate security clearance / entry access into premises of customers, vendors, consultants and other business partners”. 9 Having carefully considered all the relevant circumstances and for the reasons set out above, I find that the Organisation complied with the Transfer 7 Singapore Technologies Engineering Limited [2020] SGPDPC 21 Limitation Obligation in relation to its transfer of the Affected Individual’s Personal Data Sets to VT SAA and its other subsidiaries based in the USA. YEONG ZEE KIN DEPUTY COMMISSIONER FOR PERSONAL DATA PROTECTION 8 ",Not in Breach,e80b77152c3052ff0a5870f8773669cd59a36872,"[""tags"",""decision"",""pdf-url"",""description"",""date"",""timestamp"",""url"",""title"",""nature"",""pdf-content""]" 2023-10-01T11:02:10+08:00,fbd32491db44d3d0c97aa12a99cefd61ec954264,73,73,1,1016,A warning was issued to Water + Plants Lab for failing to put in place reasonable security arrangements to protect the personal data of its employees. The incident resulted in the personal data being subjected to a ransomware attack.,"[""Protection"", ""Warning"", ""Scientific and Technical"", ""Ransomware"", ""No Security Arrangements"", ""No Patching""]",2020-12-18,https://www.pdpc.gov.sg/-/media/Files/PDPC/PDF-Files/Commissions-Decisions/Decision--Water--Plants-Lab-Pte-Ltd--181120.pdf,Protection,Breach of the Protection Obligation by Water + Plants Lab,https://www.pdpc.gov.sg/all-commissions-decisions/2020/12/breach-of-the-protection-obligation-by-water--plants-lab,2020-12-18,"PERSONAL DATA PROTECTION COMMISSION Case No. DP-2004-B6182 In the matter of an investigation under section 50(1) of the Personal Data Protection Act 2012 And Water + Plants Lab Pte. Ltd. SUMMARY OF THE DECISION 1. On 9 April 2020, Water + Plants Lab Pte. Ltd. (the “Organisation”) informed the Personal Data Protection Commission of a ransomware infection that rendered the Organisation’s server (the “Server”) inaccessible to the Organisation (the “Incident”). 2. The Incident occurred on or around 30 March 2020. Personal data of 28 employees were encrypted by the ransomware. The personal data affected included the employees’ name, NRIC/FIN/Work Permit number, address, date of birth, mobile number and photograph. 3. Investigations revealed that an employee from the Organisation had downloaded and opened an email attachment that contained ransomware. At the time of the Incident, the Organisation had some security measures in place, for example, it had anti-virus protection, and access rights and password control for the Server. It also had a good practice of performing regular backup of its Server, and most of the data was successfully restored from an external backup. The Organisation therefore suffered minimal data loss as a result of the Incident. 4. However, as admitted by the Organisation, it had not carried out any patching and security scanning of the Server in the 12 months preceding the Incident. Patching and regular security scanning are important security measures to prevent vulnerabilities in an organisation’s ICT systems which a hacker may exploit in compromising personal data. For this reason, the Deputy Commissioner for Personal Data Protection found that the Organisation had failed to protect the personal data in its possession or under its control, in breach of section 24 of the Personal Data Protection Act 2012. 5. Following the Incident, the Organisation installed a firewall with greater capabilities to protect the Organisation against external threats, for example, possessing deeper content inspection capabilities to identify malware. The Organisation had also conducted staff training on personal data protection and on how to identify security threats. 6. Upon consideration of the facts, including the impact from the breach, the remediation action taken by the Organisation and that there was no evidence of exfiltration of the data in the Server, the Deputy Commissioner issued a warning to the Organisation. ",Warning,eee08e16b63cd4fae6c7d3775b36bf12d04f634d,"[""tags"",""decision"",""pdf-url"",""description"",""date"",""timestamp"",""url"",""title"",""nature"",""pdf-content""]" 2023-10-01T11:02:10+08:00,fbd32491db44d3d0c97aa12a99cefd61ec954264,74,74,1,1016,A warning was issued to R.I.S.E Aerospace for failing to put in place reasonable security arrangements to protect the personal data of its employees from unauthorised disclosure. The incident resulted in the personal data being subjected to a ransomware attack.,"[""Protection"", ""Warning"", ""Manufacturing"", ""Ransomware"", ""No Security Arrangements"", ""IT security policies""]",2020-12-18,https://www.pdpc.gov.sg/-/media/Files/PDPC/PDF-Files/Commissions-Decisions/Decision---RISE-Aerospace-Pte-Ltd---131120.pdf,Protection,Breach of the Protection Obligation by R.I.S.E Aerospace,https://www.pdpc.gov.sg/all-commissions-decisions/2020/12/breach-of-the-protection-obligation-by-rise-aerospace,2020-12-18,"PERSONAL DATA PROTECTION COMMISSION Case No. DP-2007-B6832 In the matter of an investigation under section 50(1) of the Personal Data Protection Act 2012 And R.I.S.E Aerospace Pte. Ltd. SUMMARY OF THE DECISION 1. On 25 August 2020, R.I.S.E Aerospace Pte Ltd (the “Organisation”) notified the Personal Data Protection Commission (the “Commission”) of a ransomware infection that had rendered its network storage server inaccessible to the Organisation (the “Incident”). 2. The Incident occurred on or about 23 August 2020. Personal data of 21 employees were encrypted by the ransomware. The personal data encrypted included the name, address, contact number, NRIC number, Work Permit details, passport details. redacted bank account numbers, and child’s date of birth. 3. Investigations revealed that the Organisation had not implemented adequate technical security arrangements to protect the personal data in its possession or control, in particular, the Organisation did not carry out any security scans or perform updates to the server firmware despite being prompted to do so by the device manufacturer. In addition, the Organisation did not put in place any documented form of IT Security policies such as its password policy, policies for patching and updating of the company server etc. These failings had resulted in a system that had vulnerabilities which a hacker could exploit by injecting ransomware into the server. 4. Following the Incident, the Organisation had since discontinued the use of its network storage server and to opt for cloud storage instead. Additionally, the Organisation also decided to encrypt all its sensitive data and only store them on offline devices. 5. In the circumstances, 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 (the “PDPA”) and took into account the following factors in deciding to issue a Warning to the Organisation. a. The low number of affected individuals; b. There was no evidence that the personal data affected in the Incident had been misused in any form; c. The Organisation had a backup copy of the encrypted personal data and did not lose any personal data as a result of the Incident; and d. The Organisation voluntary notified the Commission of the Incident. 6. In view of the remedial actions taken by the Organisation, the Commission will not be issuing any other directions. ",Warning,1400daa426845ef3c61fb74391afd631da480958,"[""tags"",""decision"",""pdf-url"",""description"",""date"",""timestamp"",""url"",""title"",""nature"",""pdf-content""]" 2023-10-01T11:02:10+08:00,fbd32491db44d3d0c97aa12a99cefd61ec954264,75,75,1,1016,"A financial penalty of $8,000 was imposed on Hello Travel for failing to put in place reasonable security arrangements to protect the personal data of its members from unauthorised disclosure.","[""Protection"", ""Financial Penalty"", ""Information and Communications"", ""Expedited"", ""Exploitation"", ""Vulnerability""]",2020-12-18,https://www.pdpc.gov.sg/-/media/Files/PDPC/PDF-Files/Commissions-Decisions/Decision---Hello-Travel-Pte-Ltd---301020.pdf,Protection,Breach of Protection Obligation by Hello Travel,https://www.pdpc.gov.sg/all-commissions-decisions/2020/12/breach-of-protection-obligation-by-hello-travel,2020-12-18,"PERSONAL DATA PROTECTION COMMISSION Case No. DP-2004-B6189 In the matter of an investigation under section 50(1) of the Personal Data Protection Act 2012 And Hello Travel Pte. Ltd. SUMMARY OF THE DECISION 1. On 8 April 2020, the Personal Data Protection Commission (the “Commission”) received information that a database belonging to Hello Travel Pte Ltd (the “Organisation”) was posted on an internet forum and was thus made publicly available (the “Incident”). 2. The Organisation subsequently requested 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 set out in this decision. It also admitted that it was in breach of section 24 of the Personal Dara Protection Act (the “PDPA”). 3. The compromised database contained the personal data of approximately 71,002 users who had created accounts at the Organisation’s website (www.havehalalwilltravel.com) from February 2015 to July 2018. The disclosed personal data included their name, email address, date of birth, nationality and phone number. The table below summarises the number of affected individuals for each corresponding type of personal data disclosed: S/N Type of Personal Data Number of Individuals Affected 4. 1 Name 71,002 2 Email Address 57,693 3 Phone Number 453 4 Date of Birth 946 5 Nationality 20,754 The Organisation’s internal investigations pointed to a possible hack as the cause of the Incident. Sometime in year 2018, the server instance which hosted the Organisation’s website and the database became corrupted and unusable after the installation of a free open source wordpress plugin. The Organisation believed that unknown parties could have exploited vulnerabilities of the installed plugin at that time and exfiltrated the database. 5. The Organisation admitted that it did not give due attention to personal data protection and had neglected to put in place basic procedural and technical security arrangements to protect the personal data in its possession and control. As examples, it did not have the relevant policies and/or protocols in place to perform regular system patching or to conduct security assessment and/or testing when making changes to its ICT systems. 6. In the circumstances, 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 (the “PDPA”). 7. Following the incident, the Organisation implemented technical measures to secure its systems from potential vulnerabilities. The personal data of its members were also encrypted immediately. Additionally, the Organisation had engaged relevant parties to take down the compromised database and informed the affected individuals of the Incident. 8. In determining the directions, if any, to be imposed on the Organisation. The Deputy Commissioner took into account the following factors: Aggravating factors (a) The high number of individuals affected; (b) The fact that personal data was exfiltrated and posted online; and (c) The Organisation did not put in place basic procedural and technical security arrangements. Mitigating factors (a) The Organisation had cooperated with the investigation; (b) The Organisation’s upfront voluntary admission of liability to a breach of the Protection Obligation under the PDPA; (c) The Organisation’s prompt remedial actions at [7] to address the inadequacies in its procedures and processes; and (d) There was no evidence that the personal data affected in the Incident had been misused in any form. 9. In the course of settling this decision, the Organisation made representation on the amount of financial penalty which the Commission intends to impose and requested that the financial penalty to be paid in instalments. The Organisation raised the following factors for the Commission’s consideration: (a) The Organisation had been suffering substantial loss due to the impact to the travel industry by the Covid-19 pandemic; and (b) The Organisation had already spent quite a substantial amount of money to fix the security breach. 10. Having carefully considered the representations, the Deputy Commissioner has decided to reduce the financial penalty to the amount set out in [11a] and is agreeable for the financial penalty to be payable in instalments. The quantum of financial penalty has been calibrated after due consideration of the Organisation’s financial circumstances due to the unprecedented challenges faced by businesses amid the current Covid-19 pandemic, bearing in mind that financial penalties imposed should not be crushing or cause undue hardship on organisations. Although a lower financial penalty has been imposed in this case, the quantum of financial penalty should be treated as exceptional and should not be taken as setting any precedent for future cases. 11. Taking into account all relevant facts and circumstances, the Deputy Commissioner hereby directs the Organisation to: (a) Pay a financial penalty of $8,000 in 10 instalments by the due dates as set out below, failing which, the full outstanding amount shall become due and payable immediately and interest at the rate specified in the Rules of Court in respect of judgment debts shall accrue and be payable on the outstanding amount of such financial penalty until the financial penalty is paid in full: i. 1st instalment of $800 on 1 January 2021; ii. 2nd instalment of $800 on 1 February 2021; iii. 3rd instalment of $800 on 1 March 2021; iv. 4th instalment of $800 on 1 April 2021; v. 5th instalment of $800 on 1 May 2021; vi. 6th instalment of $800 on 1 June 2021; vii. 7th instalment of $800 on 1 July 2021; viii. 8th instalment of $800 on 1 August 2021; ix. 9th instalment of $800 on 1 September 2021; and x. 10th instalment of $800 on 1 October 2021 12. In view of the remedial actions taken by the Organisation, the Deputy Commissioner will not be issuing any other directions. ",Financial Penalty,4d881a08a671b9937b7e44b95f8f13e43eadd144,"[""tags"",""decision"",""pdf-url"",""description"",""date"",""timestamp"",""url"",""title"",""nature"",""pdf-content""]" 2023-10-01T11:02:10+08:00,fbd32491db44d3d0c97aa12a99cefd61ec954264,76,76,1,1016,"Directions were imposed on Everlast Projects, Everlast Industries (S) and ELG Specialist for breaches of the PDPA. First, the organisations failed to put in place reasonable measures to protect their employees’ personal data. Second, they did not have written policies and practices necessary to ensure its compliance with the PDPA.","[""Accountability"", ""Protection"", ""Directions"", ""Construction"", ""No Policy"", ""Ransomware""]",2020-12-18,https://www.pdpc.gov.sg/-/media/Files/PDPC/PDF-Files/Commissions-Decisions/Decision---Everlast-Projects-and-Others---301020.pdf,"Accountability, Protection","Breach of the Accountability and Protection Obligations by Everlast Projects, Everlast Industries (S) and ELG Specialist",https://www.pdpc.gov.sg/all-commissions-decisions/2020/12/breach-of-the-accountability-and-protection-obligations-by-everlast-projects,2020-12-18,"PERSONAL DATA PROTECTION COMMISSION [2020] SGPDPC 20 Case No. DP-1908-B4369 In the matter of an investigation under section 50(1) of the Personal Data Protection Act 2012 And (1) Everlast Projects Pte Ltd (2) Everlast Industries (S) Pte Ltd (3) ELG Specialist Pte Ltd … Organisations DECISION Everlast Projects Pte Ltd & Others [2020] SGPDPC 20 Everlast Projects Pte Ltd & Others [2020] SGPDPC 20 Yeong Zee Kin, Deputy Commissioner — Case No. DP-1908-B4369 30 October 2020 Introduction 1 On 29 September 2019, Everlast Projects Pte Ltd (“EPPL”) notified the Personal Data Protection Commission (“Commission”) that its server (“Server”) had been hacked and all the files within it were encrypted by ransomware sometime in August 2019 (the “Incident”). Facts of the Case 2 EPPL, Everlast Industries (S) Pte Ltd (“EIPL”) and ELG Specialist Pte Ltd (“ESPL”) (collectively, the “Organisations”) specialise in the supply and installation of architectural metal works, glass and aluminium products. The Organisations are owned by the same shareholder, managed by the same directors, and operate from common premises. Two of the Organisations also have a common name, “Everlast”. The Organisations operated like a group of companies and centralised their payroll processing, such that the human resources (“HR”) department of EPPL was in charge of processing payrolls of not only its own employees, but also the employees of EIPL and ESPL. The Organisations’ employees’ personal data were stored in the Server, which was owned and maintained by EPPL. 3 On 10 August 2019, EPPL discovered the Incident. EPPL had both an onsite physical backup and a secondary cloud backup of the contents of the Server. The physical backup was affected by the ransomware and rendered unusable. A total of 384 individuals were affected by the Incident (the “Affected Employees”): 2 Everlast Projects Pte Ltd & Others [2020] SGPDPC 20 Name of Organisation Number of employees affected EPPL 141 EIPL 239 ESPL 4 Total number of individuals 384 4 The types of personal data of the Affected Employees that were at risk of unauthorised access included the following (collectively, the “Personal Data Sets”): (a) Name; (b) NRIC/FIN number; (c) Date of birth; (d) Bank account details; and (e) Information relating to salary. 5 The cause of the ransomware infection was not identified. EPPL’s investigations could not determine how the ransomware gained entry to the Server. EPPL was also unable to confirm whether any of the Personal Data Sets had been exfiltrated as a result of the Incident. Upon discovery of the Incident, EPPL took prompt remedial action by ceasing to use the Server immediately. 6 Findings and Basis for Determination 7 The two issues to be determined in this case are as follows: (a) Whether the Organisations had each complied with their obligations under section 12 of the Personal Data Protection Act 2012 (the “PDPA”); and (b) Whether the Organisations had each complied with their obligations under section 24 of the PDPA. 3 Everlast Projects Pte Ltd & Others [2020] SGPDPC 20 Whether EPPL, EIPL and ESPL had each complied with their obligations under section 12 of the PDPA 8 Section 12 of the PDPA requires organisations to, inter alia, develop and implement policies and practices that are necessary for the organisation to meet its obligations under the PDPA, and to communicate information about such policies and practices to its staff (the “Accountability Obligation”). 9 In this regard, it is important to reiterate that an organisation’s Data Protection Policies should be documented in a written policy, as per Re Furnituremart.sg [2017] SGPDPC 7 at [14]: “[t]he lack of a written policy is a big drawback to the protection of personal data. Without having a policy in writing, employees and staff would not have a reference for the Organisation’s policies and practices which they are to follow in order to protect personal data. Such policies and practices would be ineffective if passed on by word of mouth, and indeed, the Organisation may run the risk of the policies and practices being passed on incorrectly. Having a written policy is conducive to the conduct of internal training, which is a necessary component of an internal data protection programme.” 10 As mentioned at [2], EPPL, EIPL and ESPL operated as a group of companies in the sharing of payroll processing services, which are centralised within the HR department of EPPL. The Commission recognises the commercial benefits which arise from centralising common corporate functions within a group of companies. In such situations, one entity (the “Servicing Organisation”) provides corporate services to other entities in the same corporate group (each a “Contracting Organisation”). If the shared common corporate services involve the processing of personal data, the Servicing Organisation would be acting as a data intermediary for each Contracting Organisation.1 11 The common corporate service shared by the Organisations in the present case was the payroll processing function. EIPL and ESPL were therefore permitted to collect, without consent, their respective Affected Employees’ Personal Data Sets and 1 See the Commission’s Advisory Guidelines on Key Concepts in the PDPA (revised 2 June 2020) at [6.28]. 4 Everlast Projects Pte Ltd & Others [2020] SGPDPC 20 disclose the same to EPPL for the purposes of managing the employment relationship.2 In these circumstances, EPPL was: (a) A data controller with respect to its own Affected Employees’ Personal Data Sets; and (b) EIPL and ESPL’s data intermediary with respect to their respective Affected Employees’ Personal Data Sets that EPPL was processing on their behalf. 12 The Organisations admitted that they did not have any written data protection policies and relied only on verbal instructions to employees. Although the Organisations are in the construction industry and, in this case, do not typically collect personal data from customers, the Accountability Obligation required the Organisations to put in place data protection policies in relation to the protection of personal data of their respective employees. 13 In this regard, organisations operating as a group of companies may comply with the Accountability Obligation through binding group-level written policies or intragroup agreements that set out a common and binding standard for the protection of personal data across all organisations in the same corporate group. These binding group-level written policies or intra-group agreements are akin to binding corporate rules (“BCRs”) imposed by an organisation on its overseas recipient of the personal data (in compliance with the Transfer Limitation Obligation under Section 26(1) of the PDPA), which oblige the overseas recipient to provide a standard of protection to the transferred personal data that is at least comparable to that under the PDPA. 3 Where the corporate group is a multinational corporation (“MNC”) and the Contracting Organisation transfers personal data to an overseas Servicing Organisation, the binding group-level written policies, intra-group agreements or BCRs which meet the 2 See Second Schedule of the PDPA, para 1(o) and Fourth Schedule of the PDPA, para 1(s). The Transfer Limitation Obligation under Section 26 of the PDPA requires an organisation that transfers personal data to a country or territory outside of Singapore to take appropriate steps to ensure that the recipient of personal data is bound by legally enforceable obligations to provide to the transferred personal data a standard of protection that is at least comparable to that under the PDPA. 3 5 Everlast Projects Pte Ltd & Others [2020] SGPDPC 20 requirements of the Protection Obligation under section 24 of the PDPA4 would also meet the requirements of section 26(1) of the PDPA in relation to the Protection Obligation.5 14 In the present case, the Organisations did not have any such binding group- level written policies, intra-group agreements or BCRs. In the circumstances, I find each of EPPL, EIPL and ESPL in breach of the Accountability Obligation. Whether EPPL, EIPL and ESPL had contravened section 24 of the PDPA 15 Section 24 of the PDPA requires an organisation to protect personal data in its possession or under its control by making reasonable security arrangements to prevent unauthorised access, collection, use, disclosure, copying, modification or similar risks (the “Protection Obligation”). The obligation to make reasonable security arrangements does not attach unless the organisation is in possession or control of personal data. 16 As mentioned at [10], EPPL was (i) a data controller with respect to its own Affected Employees’ Personal Data Sets; and (ii) EIPL and ESPL’s data intermediary with respect to their Affected Employees’ Personal Data Sets that EPPL was processing on their behalf. In this regard, EPPL, EIPL and ESPL had possession and/or control of the Affected Employees’ Personal Data Sets at the material time. (a) EPPL was in possession and control of the Affected Employees’ Personal Data Sets. This was because the Organisations’ payroll processing functions were centralised within the HR department of EPPL. (b) While EIPL and ESPL did not have possession of their respective Affected Employees’ Personal Data Sets because they were centrally hosted on EPPL’s Server, I find that EIPL and ESPL remained in control of their respective Affected Employees’ Personal Data Sets as data controllers. This is because the 4 5 The Protection Obligation is explained at paragraph 14. See, for illustration, Re Cigna Europe Insurance Company S.A.-N.V. [2019] SGPDPC 18 at [13]. 6 Everlast Projects Pte Ltd & Others [2020] SGPDPC 20 processing of EIPL’s and ESPL’s Affected Employees Personal Data Sets by EPPL was for EIPL’s and ESPL’s respective business purposes.6 17 Each of the Organisations were therefore obliged to put in place reasonable security arrangements to protect the Affected Employees Personal Data Sets, including preventing the risk of unauthorised modification. In the present case, the Commission’s investigations into the Incident revealed that the ransomware had encrypted all the files in the Server and its physical backup, including the Affected Employees’ Personal Data Sets. The unauthorised modification of the Affected Employees’ Personal Data Sets by the ransomware made it unreadable and unusable. 18 It is well established that a data controller should have in place a written contract with its data intermediary that clearly specifies the data intermediaries’ obligation to protect personal data. 7 That said, the relationship between the Organisations is a relevant factor in determining the reasonable security measures expected of them to comply with the Protection Obligation. In this regard, for a group of companies, the written contract requirement between a Servicing Organisation and the Contracting Organisation may be met by binding group-level written policies, intra-group agreements or BCRs as discussed at [13] above. 19 In addition to a written agreement specifying data protection requirements, a Contracting Organisation should also implement operational processes so as to be able to exercise some form of supervision or control over the activities of the Servicing Organisation when it processes personal data on the Contracting Organisation’s behalf.8 Where the Servicing Organisation has specialised knowledge, skills and/or tools for processing personal data, having a robust audit framework could be an appropriate form of oversight. This may be particularly suited for MNCs which typically 6 See Re The Cellar Door Pte Ltd and another [2016] SGPDPC 22 at [17] – [18]; Re AIG Asia Pacific Insurance Pte Ltd [2018] SGPDPC 8 at [18]. 7 See the Commission’s Guide on Data Protection Clauses for Agreements relating to the Processing of Personal Data (20 July 2016) at [4]; Re Singapore Telecommunications Limited [2017] PDPC 4 at [14] 8 The Commission’s Advisory Guidelines on Key Concepts in the PDPA (revised 2 June 2020) at [17.5] provides that “[e]nsuring that IT service providers are able to provide the requisite standard of IT security” is an example of a technical measure an organisation may use to protect personal data. 7 Everlast Projects Pte Ltd & Others [2020] SGPDPC 20 conduct periodic internal and/or external audits and assessments to monitor compliance by each organisation within the corporate group.9 Conversely, small and medium-sized enterprises that only operate in Singapore are less likely to conduct such compliance audits on each organisation in the corporate group in the areas of cybersecurity and/or data protection. In such situations, appropriate oversight could involve more simple processes. For example, requiring the Servicing Organisation to explain to the Contracting Organisation the measures which would be taken to secure personal data, with appropriate documentation to evidence this process (e.g. written acknowledgement given by the Contracting Organisation to the Servicing Organisation), and provide regular reports showing that it has put these processes in place. 20 In the present case, both EIPL and ESPL failed to put in place reasonable security arrangements to ensure that EPPL (who was their data intermediary for the purposes of payroll processing) would protect their respective Affected Employees’ Personal Data Sets. There was no written contract, intra-group agreement or grouplevel written policies/BCRs setting out data protection requirements that EPPL was obliged to comply with when processing EIPL’s and ESPL’s respective Affected Employees’ Personal Data Sets. Notwithstanding that the Organisations conducted their business operations from the same premises, both EIPL and ESPL also did not implement any operational processes to supervise or exercise some form control over EPPL to ensure EPPL protected their Affected Employees’ Personal Data Sets. In the circumstances, I find each of EIPL and ESPL in breach of the Protection Obligation. 21 EPPL was also obliged to comply with the Protection Obligation. As mentioned in [10], it was: (i) a data controller with respect to its own Affected Employees’ Personal Data Sets; and (ii) EIPL and ESPL’s data intermediary with respect to their Affected Employees’ Personal Data Sets. The Commission’s Investigations revealed that EPPL did not put in place reasonable security arrangements to protect the Personal Data Sets as explained below: 9 As an example, see Re Cigna Europe Insurance Company S.A.-N.V. [2019] SGPDPC 18 at [7(c)]. 8 Everlast Projects Pte Ltd & Others (a) [2020] SGPDPC 20 EPPL did not install a firewall for the Server. Without a firewall, the Server and corporate network was vulnerable to web-based security threats;10 (b) EPPL did not conduct periodic security reviews of its IT systems, including vulnerability scans of the Server, to assess the overall security of its IT infrastructure. The requirement for organisations to conduct periodic security reviews of its IT systems has been emphasized in previous decisions. 11 Conducting regular information and communication technology (“ICT”) security audits, scans and tests to detect vulnerabilities help organisations to ensure that ICT security controls developed and configured for the protection of personal data are properly implemented. 12 The comprehensiveness of such security reviews should be scoped based on the organisation’s assessment of its data protection needs, and be conducted to a reasonable standard. The scope and level of the review would depend on the type of personal data to be protected. In this case, as the Personal Data Sets included personal data of a financial nature (e.g. information relating to bank accounts and salaries), a higher standard of periodic security review was required of EPPL in order to comply with the Protection Obligation. If EPPL had conducted a security review of its IT system to a reasonable standard, it would have discovered the absence of a firewall for the Server; and (c) EPPL was unable to provide any written IT security policies (e.g. password policy, policies for patching and updating of the company server, etc.). 13 In this regard, EPPL conceded that they did not know what was required in order to protect personal data in electronic form. 10 The Commission’s Guide to Securing Personal Data in Electronic Medium (20 January 2017) at [9.1] states as follows: “It is important for an organisation to ensure that its corporate computer networks are secure. Vulnerabilities in the network may allow cyber intrusion, which may lead to theft or unauthorised use of electronic personal data. Defences that may be used to improve the security of networks include: […] Firewalls”. 11 See, for example, Re WTS Automotive Services Pte. Ltd. [2018] SGPDPC 26 at [18], Re Bud Cosmetics [2019] SGPDPC 1 at [24] and Re Chizzle Pte. Ltd. [2019] SGPDPC 44 at [6] to [8]. 12 Commission’s Guide to Securing Personal Data in Electronic Medium (revised 20 January 2017) at [6.1]. 13 The Commission’s Advisory Guidelines on Key Concepts in the PDPA (revised 2 June 2020) at [17.5] provides that “[s]ecurity arrangements may take various forms such as administrative measures, physical measures, technical measures or a combination of these”. Having robust policies and procedures is an example of an administrative measure an organisation may implement by way of security arrangements. 9 Everlast Projects Pte Ltd & Others 22 [2020] SGPDPC 20 For the reasons above, I also find EPPL in breach of the Protection Obligation. Directions 23 In determining the directions, if any, to be imposed on EPPL, EIPL and ESPL under section 29 of the PDPA, I took into account the following factors: (a) The Organisations had voluntarily notified the Commission of the Incident; (b) The Commission did not receive any complaints of the Personal Data Sets being disclosed online or otherwise misused; (c) There was no evidence of exfiltration of the Personal Data Sets; and (d) An imposition of a financial penalty would impose a crippling burden and cause undue financial hardship due to the financial position of the Organisations. 24 Having considered all the relevant factors of this case, I direct EPPL, EIPL and ESPL to: (a) Develop and implement intra-group agreements or binding corporate rules that set out a common and binding standard for the processing of personal data when centralising common corporate activities within the group, within 90 days from the date of this direction; (b) Review and ensure that the internal policies within each of EPPL, EIPL and ESPL are in line with the standards set forth in the intra-group agreements or binding corporate rules, within 90 days from the date of this direction; and (c) Inform the Commission of the completion of the directions set out at [23(a)] and [23(b)] within one week. YEONG ZEE KIN DEPUTY COMMISSIONER FOR PERSONAL DATA PROTECTION 10 ",Directions,6bf33286d1c3d26557836242297e0273d9b08921,"[""tags"",""decision"",""pdf-url"",""description"",""date"",""timestamp"",""url"",""title"",""nature"",""pdf-content""]" 2023-10-01T11:02:10+08:00,fbd32491db44d3d0c97aa12a99cefd61ec954264,77,77,1,1016,"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,"[""tags"",""decision"",""pdf-url"",""description"",""date"",""timestamp"",""url"",""title"",""nature"",""pdf-content""]" 2023-10-01T11:02:10+08:00,fbd32491db44d3d0c97aa12a99cefd61ec954264,78,78,1,1016,"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,"[""tags"",""decision"",""pdf-url"",""description"",""date"",""timestamp"",""url"",""title"",""nature"",""pdf-content""]" 2023-10-01T11:02:10+08:00,fbd32491db44d3d0c97aa12a99cefd61ec954264,79,79,1,1016,"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,"[""tags"",""decision"",""pdf-url"",""description"",""date"",""timestamp"",""url"",""title"",""nature"",""pdf-content""]" 2023-10-01T11:02:10+08:00,fbd32491db44d3d0c97aa12a99cefd61ec954264,80,80,1,1016,"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,"[""tags"",""decision"",""pdf-url"",""description"",""date"",""timestamp"",""url"",""title"",""nature"",""pdf-content""]" 2023-10-01T11:02:10+08:00,fbd32491db44d3d0c97aa12a99cefd61ec954264,81,81,1,1016,"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,"[""tags"",""decision"",""pdf-url"",""description"",""date"",""timestamp"",""url"",""title"",""nature"",""pdf-content""]" 2023-10-01T11:02:10+08:00,fbd32491db44d3d0c97aa12a99cefd61ec954264,82,82,1,1016,Directions were issued to Security Masters for failing to put in place reasonable security arrangements to prevent the unauthorised access of building visitors’ mobile numbers. A security personnel contacted the visitors to request return of visitor passes and send them Chinese New Year greetings.,"[""Protection"", ""Directions"", ""Others"", ""Text messages"", ""Mobile numbers"", ""Protection""]",2020-10-16,https://www.pdpc.gov.sg/-/media/Files/PDPC/PDF-Files/Commissions-Decisions/Decision---Security-Masters-Pte-Ltd---21072020.pdf,Protection,Breach of the Protection Obligation by Security Masters,https://www.pdpc.gov.sg/all-commissions-decisions/2020/10/breach-of-the-protection-obligation-by-security-masters,2020-10-16,"PERSONAL DATA PROTECTION COMMISSION Case No. DP-2002- B5875 In the matter of an investigation under section 50(1) of the Personal Data Protection Act 2012 And Security Masters Pte Ltd SUMMARY OF THE DECISION 1. On 17 February 2020, Security Masters Pte Ltd (the “Organisation”) notified the Personal Data Protection Commission (the “Commission”) that a security employee had used the mobile phone numbers of eight building visitors to contact them to request their return of visitor passes and send them Chinese New Year greetings. 2. Investigation found that the Organisation did not put in place any standard operating procedure or guidelines for the retrieval and use of visitors’ personal data prior to the incident. This gap in security arrangements allowed the incident to occur. 3. The Deputy Commissioner for Personal Data Protection therefore found that the Organisation did not adopt reasonable steps to protect personal data in its possession or under its control against risk of unauthorised access. The Organisation was in breach of the Protection Obligation under section 24 of the Personal Data Protection Act 2012. 4. Following the incident, the Organisation restricted access to personal data to senior personnel and required all security personnel to sign an undertaking not to contact visitors in their personal capacity. However, structured training is needed to help its security personnel understand the importance of protecting the personal data they handled daily in their duties, such as National Registration Identification Card numbers, photographs and closed-circuit television footage. 5. On the above consideration, the Deputy Commissioner for Personal Data Protection hereby directs the Organisation to: a) Within 60 days from the date of the direction, revise its training curriculum to ensure that its security personnel understand i. the rationale for personal data protection; ii. the importance of consent and authorisation in the handling of personal data; and iii. the circumstances in which it would be appropriate to use and disclose personal data on social media platforms for work-related purposes; and b) Inform the Commission within 1 week of implementation of the above. ",Directions,e24e6989567857bec320cd7ad6365fd535330a52,"[""tags"",""decision"",""pdf-url"",""description"",""date"",""timestamp"",""url"",""title"",""nature"",""pdf-content""]" 2023-10-01T11:02:10+08:00,fbd32491db44d3d0c97aa12a99cefd61ec954264,83,83,1,1016,A warning was issued to Interauct! for retaining personal data which was no longer necessary for legal or business purposes.,"[""Retention Limitation"", ""Warning"", ""Others"", ""Backup files"", ""Server migration""]",2020-10-16,https://www.pdpc.gov.sg/-/media/Files/PDPC/PDF-Files/Commissions-Decisions/Decision---Interauct-Pte-Ltd---04082020.pdf,Retention Limitation,Breach of the Retention Limitation Obligation by Interauct!,https://www.pdpc.gov.sg/all-commissions-decisions/2020/10/breach-of-the-retention-obligation-by-interauct,2020-10-16,"PERSONAL DATA PROTECTION COMMISSION Case No. DP-1911-B5268 In the matter of an investigation under section 50(1) of the Personal Data Protection Act 2012 And Interauct! Pte Ltd SUMMARY OF THE DECISION 1. Interauct! Pte Ltd (the “Organisation”) operated an online mobile number auction (the “Auction”) for a telecommunications provider (the “Telco”). This arrangement started in the year 2000 and ended in 2018. 2. In November 2019, the Commission was informed that the Telco’s cybersecurity team had located an internet sub-domain containing files with the personal data of individuals who had participated in the Auction (the “Files”). The Files contained the following types of personal data: a. Name; b. ID (such as passport or NRIC number); c. Mobile number; d. Address; e. Date of birth; and f. Email address. 3. The Commission’s investigations revealed the following: a. The Organisation had engaged a vendor to provide web hosting services for the Auction. In 2012 and 2016, the vendor conducted server migration exercises. On both occasions, the Organisation created backups of the Files prior to server migration exercises and uploaded them on the vendor’s servers. The Organisation did not delete the Files after the server migration were completed; b. In April 2019, the vendor misconfigured its servers. As a result, the Files became accessible on the internet sub-domain. However, to access this sub-domain requires an individual to key in either one of two URLs exactly. Both URLs were complex and lengthy. It was therefore difficult for an individual to determine the URLs exactly to enter the sub-domain. Indeed, an examination of server logs found that only the Telco had accessed the sub-domain; c. The Files contained a mix of individuals’ personal data, as well as dummy data used for testing purposes. An analysis of the Files showed that there were approximately 8,750 individuals’ personal data contained in them. The Telco compared the data with its customer records, and via a reconciliation process, was able to identify 3,380 individuals as its customers. In this regard, the Telco informed that it would have been very difficult for a third party, without access to the Telco’s customer records, to carry out such a reconciliation exercise. This means that even if an individual had accessed the Files, it would have been difficult to him to identify the individuals from the personal data in the Files; d. The Organisation deleted the Files within three hours of the Telco notifying the Organisation of their discovery of the internet sub-domain. The Organisation had also ensured that the vendor fixed the misconfiguration of the servers, which was done within six hours of the discovery of the internet sub-domain. 4. The Deputy Commissioner for Personal Data Protection (the “Deputy Commissioner”) finds that the Organisation had put in place, via the vendor, reasonable security arrangements to protect the personal data. In particular, the security arrangements in place would have prevented direct access by unauthorised third-parties to the Files hosted on the server. This had greatly reduced the potential adverse impact of the incident. 5. However, the Organisation admitted that there was no reason to retain the Files after the migration exercises were completed. If the Files had been duly deleted, the personal data in the Files would not have been compromised in the first place. The Deputy Commissioner therefore finds the Organisation in breach of the Retention Limitation Obligation under section 25 of the Personal Data Protection Act 2012. 6. After considering the facts and circumstances of the incident, including the fact that the personal data in the Files was ultimately not exposed, the Deputy Commissioner has decided to issue a warning to the Organisation for the breach of the Retention Limitation Obligation. No other direction is required as the breach has been remedied. ",Warning,5932047a3ee552243babdc8b5564ced3e448d87b,"[""tags"",""decision"",""pdf-url"",""description"",""date"",""timestamp"",""url"",""title"",""nature"",""pdf-content""]" 2023-10-01T11:02:10+08:00,fbd32491db44d3d0c97aa12a99cefd61ec954264,84,84,1,1016,"A warning was issued to Chan Brothers Travel for failing to put in place reasonable security arrangements to protect the personal data of individuals on its website. The result was that the personal data of over 5,500 individuals were accessible through online web search engines.","[""Protection"", ""Warning"", ""Arts, Entertainment and Recreation"", ""Access control"", ""SEO indexing""]",2020-10-16,https://www.pdpc.gov.sg/-/media/Files/PDPC/PDF-Files/Commissions-Decisions/Decision---Chan-Brothers-Travel-Pte-Ltd---21072020.pdf,Protection,Breach of the Protection Obligation by Chan Brothers Travel,https://www.pdpc.gov.sg/all-commissions-decisions/2020/10/breach-of-the-protection-obligation-by-chan-brothers-travel,2020-10-16,"PERSONAL DATA PROTECTION COMMISSION Case No. DP-1905-B3936 In the matter of an investigation under section 50(1) of the Personal Data Protection Act 2012 And Chan Brothers Travel Pte Ltd SUMMARY OF THE DECISION 1. On 23 May 2019, the Personal Data Protection Commission (the “Commission”) received a data breach notification from Chan Brothers Travel Pte Ltd (the “Organisation”) and a complaint from a member of the public. Both were in relation to personal data being at risk of unauthorised access through the Organisation’s website at http://chanbrotherstravelclub.force.com (the “Website”) (the “Incident”). 2. In March 2017, the Organisation purchased Community Cloud, a product of Salesforce.com Singapore Pte Ltd (“Salesforce”), to host the Website. The Organisation managed the Website internally. In August 2018, the Organisation engaged Aodigy Asia Pacific Pte Ltd (“Aodigy”) as an outsource vendor to maintain and improve the Website. 3. The Website provided three online forms for enquiries and feedback. These were the “Enquiry Form”, Feedback Form” and “Post-Tour Feedback Form” (collectively the “Forms”). The Forms collected the users’ names, email addresses and mobile phone numbers. 4. In March 2018, there was a software update released by Salesforce for Community Cloud. This software update included an automated search engine optimisation feature (the “SEO”). As the Website’s access configuration was set to “Public”, the Forms automatically inherited the same setting for the purpose of the SEO feature. The result was that the personal data of an estimated 5,593 individuals collected by the Forms were indexed and cached, and made searchable, through online web search engines. 5. Organisations that employ IT systems or features are responsible for data security. Organisations must acquire knowledge of the security settings and be aware of security implications of software features of their IT system, and they must configure the security settings to enable effective protection of personal data stored in the IT system. This responsibility extends to new features introduced by subsequent software releases. Organisations that lack the IT knowledge to discharge this responsibility should engage qualified assistance. 6. The Organisation failed to consider the implication of the “Public” setting of the Website on the security of the data collected by the Forms. It also failed to understand the function and operation of the SEO feature. The combination of these acts of omission resulted in the security issues arising leaving the SEO feature enabled. 7. The Organisation claimed not to have received any notification from Salesforce of the SEO release. However, this is contradicted by the following. First, the notes of the software release was published on the website of Salesforce. Second, Aodigy had (in its role as vendor for another project) received information of the release. On balance, it is therefore unlikely that Salesforce would have omitted to notify the Organisation about the software release. In any event, the software release was in March 2018 when the Organisation was still maintaining the Website internally. The responsibility to assess the security implications of the software release laid squarely on its shoulders during that 5-month period before Aodigy was engaged. 8. Further, there is some uncertainty over whether Aodigy was instructed to review the security configuration of the Website (including the new software features) as part of its maintenance services when it was engaged. The Organisation did not give clear instructions to Aodigy to assess the security configuration of the IT system as part of the maintenance services. 9. In the circumstances, the Deputy Commissioner for Personal Data Protection therefore found the Organisation in breach of section 24 of the Personal Data Protection Act 2012 and took into account the following factors in deciding to issue a Warning to the Organisation: a. The personal data at risk of disclosure was limited to names, email address and contact numbers, apart from an estimated 50 NRIC numbers. b. The Organisation voluntary notified the Commission of the Incident. c. Prompt co-operation in the course of the Commission’s investigations. 10. No directions are required as the Organisation took immediate steps to prevent the recurrence of the Incident. ",Warning,1371e96aee9b5458d29ef161ea0de43abb7b1200,"[""tags"",""decision"",""pdf-url"",""description"",""date"",""timestamp"",""url"",""title"",""nature"",""pdf-content""]" 2023-10-01T11:02:10+08:00,fbd32491db44d3d0c97aa12a99cefd61ec954264,85,85,1,1016,"A financial penalty of $4,000 was imposed on Tanah Merah Country Club for failing to put in place reasonable security arrangements to protect the personal data of individuals stored on its electronic direct mail (“EDM”) system. The common password for login to the EDM system was weak and had not been changed since 2010. There were also no arrangements in place to ensure and enforce password strength, expiry and protection. An application for reconsideration was filed against the decision Re Tanah Merah Country Club. Upon review and careful consideration of the application, directions in the decision were varied.","[""Protection"", ""Financial Penalty"", ""Arts, Entertainment and Recreation"", ""EDM"", ""Password"", ""Weak password""]",2020-10-16,https://www.pdpc.gov.sg/-/media/Files/PDPC/PDF-Files/Commissions-Decisions/Decision---Tanah-Merah-Country-Club---21072020.pdf,Protection,Breach of the Protection Obligation by Tanah Merah Country Club,https://www.pdpc.gov.sg/all-commissions-decisions/2020/10/breach-of-the-protection-obligation-by-tanah-merah-country-club,2020-10-16,"PERSONAL DATA PROTECTION COMMISSION Case No. DP-1906-B4115 In the matter of an investigation under section 50(1) of the Personal Data Protection Act 2012 And Tanah Merah Country Club Editorial note: An application for reconsideration was filed against the decision in Re Tanah Merah Country Club. Pursuant to this application, the Commissioner has decided to reduce the financial penalty imposed on the Organisation from $8,000 to $4,000. As the application did not give rise to significant legal or factual issues, a separate decision on the application will not be published. SUMMARY OF THE DECISION 1. On 19 June 2019, Tanah Merah Country Club (the “Organisation”) informed the Personal Data Protection Commission (the “Commission”) of unauthorised access to its electronic direct mail (“EDM”) system (the “Incident”). During the Incident, which occurred on 9 June 2019, the EDM system was used to send unauthorised spam emails. 2. The Organisation was unable to determine how unauthorised access was gained to the EDM system. During investigations, it was discovered that the common password for login to the EDM system was weak, as it comprised the initials of the Organisation and the year 2010 (which was the year that the EDM system was set up). The password was shared by at least 3 persons: 2 of the Organisation’s marketing staff and its technical support vendor. Further, it had not been changed since 2010. Investigations disclosed that there were no arrangements in place to ensure and enforce password strength, expiry and protection. 3. In the circumstances, although the means of unauthorised access to the EDM system was not determined, the evidence pointed to weak password control as the cause. The Deputy Commissioner for Personal Data Protection therefore found the Organisation in breach of section 24 of the Personal Data Protection Act 2012. 4. The Organisation is directed to pay a financial penalty of $8,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 the financial penalty until the financial penalty is paid in full. In view of the remedial measures taken by the Organisation, the Commission will not issue any other directions. 5. The Organisation’s prompt co-operation in the course of the Commission’s investigation and its prompt actions taken to remediate the breach were taken into consideration in determining the quantum of the financial penalty. ",Financial Penalty,e641872fa69f2e946b7cb68cb7e884c4c88db9c2,"[""tags"",""decision"",""pdf-url"",""description"",""date"",""timestamp"",""url"",""title"",""nature"",""pdf-content""]" 2023-10-01T11:02:10+08:00,fbd32491db44d3d0c97aa12a99cefd61ec954264,86,86,1,1016,"A financial penalty of $5,000 was imposed on Vimalakirti Buddhist Centre for failing to put in place reasonable security arrangements to protect the personal data of its members and non-members from unauthorised disclosure. The incident resulted in the personal data being subjected to a ransomware attack.","[""Protection"", ""Financial Penalty"", ""Others"", ""Ransomware"", ""No measures""]",2020-10-16,https://www.pdpc.gov.sg/-/media/Files/PDPC/PDF-Files/Commissions-Decisions/Decision---Vimalakirti-Buddhist-Centre---04092020.pdf,Protection,Breach of the Protection Obligation by Vimalakirti Buddhist Centre,https://www.pdpc.gov.sg/all-commissions-decisions/2020/10/breach-of-the-protection-obligation-by-vimalakirti-buddhist-centre,2020-10-16,"PERSONAL DATA PROTECTION COMMISSION Case No. DP-2004-B6193 In the matter of an investigation under section 50(1) of the Personal Data Protection Act 2012 And Vimalakirti Buddhist Centre SUMMARY OF THE DECISION 1. On 14 April 2020, Vimalakirti Buddhist Centre (the “Organisation”) notified the Personal Data Protection Commission (the “Commission”) of a ransomware infection that had rendered its data management system inaccessible by the Organisation (the “Incident”). 2. The Organisation subsequently requested 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 set out in this decision. It also admitted that it was in breach of section 24 of the Personal Dara Protection Act (the “PDPA”). 3. The Incident occurred on or about 31 March 2020. Personal data of approximately 4,500 members and 4,000 non-members (total 8,500 individuals) were encrypted by the ransomware. The personal data encrypted included the name, address, contact number, NRIC number, date of birth and donation details of the individuals. 4. The Organisation admitted it did not give due attention to personal data protection, and had neglected to implement both procedural and technical security arrangements to protect the personal data in its possession and control. Consequently, it did not have the relevant security software and/or protocols in place to prevent the ransomware from entering its data management system. 5. In the circumstances, 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 (the “PDPA”). 6. Following the incident, the Organisation set up a new server with backup from 21 October 2019. For the data collected by the Organisation from 22 October 2019 to the Incident, the Organisation had retrieved the data from physical file records and restored them in the new server. It also installed a firewall to filter network traffic to and from the new server, and cleaned, restored and reinstalled all computers connected to its data management system. Additionally, the Organisation committed to engage consultants to help produce a data protection manual and train its staff in cyber hygiene and incident response. 7. The Deputy Commissioner for Personal Data Protection notes that the Organisation had admitted to a breach of Protection Obligation under the PDPA, cooperated with the Commission’s investigation and taken prompt remedial action. There was no evidence that the personal data affected in the Incident had been misused in any form. In addition, the Organisation had a backup copy of the encrypted data and did not lose any data as a result of the Incident. Accordingly, the practice of having data backup(s) should be encouraged to prevent organisations from losing data in the event of ransomware. 8. 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). 9. In view of the remedial actions taken by the Organisation, the Commission will not be issuing any other directions. ",Financial Penalty,e0f3f4b9ea5a6f7fe98f703d2b0a529a93f64315,"[""tags"",""decision"",""pdf-url"",""description"",""date"",""timestamp"",""url"",""title"",""nature"",""pdf-content""]" 2023-10-01T11:02:10+08:00,fbd32491db44d3d0c97aa12a99cefd61ec954264,87,87,1,1016,A warning was issued to Horizon Fast Ferry for failing to put in place reasonable security arrangements to protect the personal data in the Organisation’s email account.,"[""Protection"", ""Warning"", ""Others"", ""Password policy"", ""Email account"", ""Phishing""]",2020-10-16,https://www.pdpc.gov.sg/-/media/Files/PDPC/PDF-Files/Commissions-Decisions/Decision----Horizon-Fast-Ferry-Pte-Ltd---27082020.pdf,Protection,Breach of the Protection Obligation by Horizon Fast Ferry,https://www.pdpc.gov.sg/all-commissions-decisions/2020/10/breach-of-the-protection-obligation-by-horizon-fast-ferry,2020-10-16,"PERSONAL DATA PROTECTION COMMISSION Case No. DP-1912-B5465 In the matter of an investigation under section 50(1) of the Personal Data Protection Act 2012 And Horizon Fast Ferry Pte. Ltd. SUMMARY OF THE DECISION 1. The Personal Data Protection Commission (“Commission”) investigated a complaint against Horizon Fast Ferry Pte. Ltd. (the “Organisation”) where the Organisation’s email account, singapore@horizonfastferry.com (the “Email Account”) had sent out phishing emails to its customers (the “Incident”). 2. Investigations revealed that the computer used to access the Email Account was infected with malware. This caused the Email Account to send phishng emails to three customers. Each email contained only the personal data that the customer himself had sent to the Email Account to book ferry tickets. Hence there was no disclosure of other customers’ personal data in the phishing email. 3. The Organisation informed the Commission that it had implemented various security measures prior to the Incident such as updating their anti-virus software regularly. However, investigations revealed that the password to access the Email Account was shared by 11 employees of the Organisation and had not been changed for almost 3 years. This poor management of passwords fell short of what is reasonably required to protect the personal data in the Email Account. 4. The Deputy Commissioner for Personal Data Protection therefore found that the Organisation in breach of the Protection Obligation under section 24 of the Personal Data Protection Act 2012 for failing to implement reasonable security arrangements to protect the personal data in its possession or under its control. Upon consideration of the facts, a warning was issued to the Organisation. ",Warning,a9f0d524ae6cbf14f4db5cdf1e0ccba42e45b1e0,"[""tags"",""decision"",""pdf-url"",""description"",""date"",""timestamp"",""url"",""title"",""nature"",""pdf-content""]" 2023-10-01T11:02:10+08:00,fbd32491db44d3d0c97aa12a99cefd61ec954264,88,88,1,1016,"A warning was issued to MRI Diagnostics for failing to put in place reasonable security arrangements to prevent the unauthorised disclosure of personal data of approximately 4,099 individuals which were publicly available via the internet. Directions were imposed on Clarity Radiology for failing to appoint a data protection officer and not having policies and practices necessary to comply with the PDPA.","[""Protection"", ""Warning"", ""Healthcare"", ""Excel spreadsheet"", ""Access restriction"", ""Patching"", ""Policies""]",2020-10-16,https://www.pdpc.gov.sg/-/media/Files/PDPC/PDF-Files/Commissions-Decisions/Decision---MRI-Diagnostics-Pte-Ltd-and-Other---22072020.pdf,Protection,Breach of the Protection Obligation by MRI Diagnostics and Breach of the Accountability Obligation by Clarity Radiology,https://www.pdpc.gov.sg/all-commissions-decisions/2020/10/breach-of-the-protection-obligation-by-mri-diagnostics-and-breach-of-the-accountability-obligation-by-clarity-radiology,2020-10-16,"PERSONAL DATA PROTECTION COMMISSION Case No. DP-1811-B2975 In the matter of an investigation under section 50(1) of the Personal Data Protection Act 2012 And (1) MRI Diagnostics Pte Ltd (2) Clarity Radiology Pte Ltd SUMMARY OF THE DECISION 1. MRI Diagnostics Pte Ltd (“NovenaMRI”) operates a medical centre that provides magnetic resonance imaging and X-Ray services to patients. In the course of their business, NovenaMRI subscribed to an internet based teleradiology system (“System”) provided by Clarity Radiology Pte Ltd (“Clarity”). In-turn, Clarity engaged an overseas IT vendor (the “IT Vendor”) to maintain the System. 2. On 7 November 2018, a patient of NovenaMRI (“Complainant”) notified the Personal Data Protection Commission (the “Commission”) about an Excel Spreadsheet containing approximately 600 individual’s personal data (including the Complainant’s) that was accessible via the internet (the “Incident”). 3. During the course of investigations, the Commission found two additional Excel Spreadsheets containing similar information as the Excel Spreadsheet reported by the Complainant. A total of approximately 4,099 individuals were affected by the Incident (“Affected Individuals”). The Affected Individuals’ personal data that was exposed to unauthorised access included their names, NRIC numbers and the type of radiology scans performed (collectively, the “Personal Data Sets”). 4. The Commission’s investigations revealed that the Incident was caused by a lapse in the IT Vendor’s processes while carrying out maintenance work on the System. In particular, the IT Vendor had removed access restrictions to a network folder containing the Excel Spreadsheets for the purposes of patching the System, and omitted to reinstate the access restrictions after the patching was completed. Without access restrictions, the Excel Spreadsheets (containing the Personal Data Sets) were indexed by Google’s search engines and exposed to unauthorised access. 5. NovenaMRI was an organisation who had collected the Personal Data Sets from its patients, and had control of the Personal Data Sets at all material times. 6. Section 24 of the Personal Data Protection Act (“PDPA”) requires organisations like NovenaMRI to protect personal data in its possession or under its control by making reasonable security arrangements to prevent unauthorised access, collection, use, disclosure, copying, modification or similar risks (the “Protection Obligation”). In this regard, the Deputy Commissioner for Personal Data Protection (“Deputy Commissioner”) finds NovenaMRI in breach of the Protection Obligation because: (a) When an organisation engages a vendor to supply, modify and/or maintain its IT system, it is required to provide the vendor with sufficient clarity and specifications on the requirements to protect personal data. This is because even if the vendor was not engaged to process personal data on the organisation’s behalf, it may nevertheless handle the personal data incidentally or make decisions that affect the security of the personal data in the course of providing its services. Depending on the circumstances of each case, the organisation should articulate its business requirements concerning the protection of personal data that the IT system will store. This will enable the vendor to assess and recommend the most appropriate and effective method to protect personal data. The organization will then be able to make a decision with access to the right information. Examples of measures include having clauses in written agreements setting out clearly the vendor’s obligations to protect personal data, providing operational guidance and verifying the data protection arrangements implemented by the vendor and/or exercising some form of supervision and oversight over the vendor’s activities; (b) Given the nature of NovenaMRI’s business, which entailed being in possession and/or control of personal data of a sensitive nature (e.g. radiology scans and X-Rays), NovenaMRI should also have conducted a proper assessment of its vendor to satisfy itself that the vendor is wellplaced to protect the personal data it hosts. For example, NovenaMRI could have obtained documentary evidence that the vendor had complied with industry standards with respect to information security (eg the ISO 27001 standard). However, in this case, there was no evidence that NovenaMRI had conducted proper due diligence of the security standards put in place by Clarity, prior to subscribing to the System that provided cloud-based services, including hosting the Personal Data Sets; (c) Although NovenaMRI claimed that it had a written agreement with Clarity, it was unable to produce supporting evidence of this. NovenaMRI’s claim was also disputed by Clarity, who had admitted that there was no written agreement between the parties. In addition, even after NovenaMRI had engaged Clarity, NovenaMRI did not take any steps to verify if Clarity had implemented any data protection arrangements with respect to the System which hosted the Personal Data Sets. 7. As for Clarity, the contracted services from Clarity to NovenaMRI were to provide an archive for Dicom Images and a Web-based radiology information system with scheduling, registration, billing and client access modules. Essentially, Clarity was a “Software as a Service” provider (or what is commonly known as “SaaS-provider”) who had provided its cloud-based services to NovenaMRI. The provision of such technical solutions or deployment of software integrated into the clinical devices of NovenaMRI did not entail the processing of personal data. As such, Clarity was a vendor of NovenaMRI, and not a “data intermediary” of NovenaMRI. As a vendor, Clarity was not responsible for the protection of the Personal Data Sets under the PDPA in respect of the Incident. 8. However, during the course of investigations, Clarity admitted that it had failed to appoint a data protection officer and had not developed or put in place any data protection policies, as required under Sections 11(3) and 12 of the PDPA. Accordingly, Clarity is in breach of Sections 11(3) and 12 of the PDPA. 9. After considering the circumstances of the case, the Deputy Commissioner’s decisions are as follows: (a) to issue a warning to NovenaMRI for its breach of the Protection Obligation. No further directions are necessary as NovenaMRI has ceased its business relationship with Clarity; and (b) to direct that Clarity shall, within 30 days from the date of this decision: i. Appoint a data protection officer; ii. Develop and implement a data protection policy to comply with its obligations under the PDPA; and iii. Inform the Commission within 7 days of the completion of each of the above directions. ",Warning,8906873bf2bf8d94f7c7b01b729303a770c83162,"[""tags"",""decision"",""pdf-url"",""description"",""date"",""timestamp"",""url"",""title"",""nature"",""pdf-content""]" 2023-10-01T11:02:10+08:00,fbd32491db44d3d0c97aa12a99cefd61ec954264,89,89,1,1016,"A financial penalty of $9,000 was imposed on COURTS for failing to put in place reasonable security arrangements to protect the personal data of its members from unauthorised disclosure on its website. Some members were able to gain access to personal data of another member via a link in an email sent by COURTS.","[""Protection"", ""Financial Penalty"", ""Wholesale and Retail Trade"", ""Inadequate scoping of testing"", ""EDM"", ""Incorrect Setting""]",2020-10-16,https://www.pdpc.gov.sg/-/media/Files/PDPC/PDF-Files/Commissions-Decisions/Decision---COURTS-Singapore---140820.pdf,Protection,Breach of the Protection Obligation by COURTS,https://www.pdpc.gov.sg/all-commissions-decisions/2020/10/breach-of-the-protection-obligation-by-courts,2020-10-16,"PERSONAL DATA PROTECTION COMMISSION [2020] SGPDPC 17 Case No DP-1909-B4731 In the matter of an investigation under section 50(1) of the Personal Data Protection Act 2012 And COURTS (Singapore) Pte Ltd. … Organisation DECISION COURTS (Singapore) Pte Ltd [2020] SGPDPC 17 Lew Chuen Hong, Commissioner — Case No DP-1909-B4731 14 August 2020 Introduction 1 On 6 September 2019, COURTS (Singapore) Pte Ltd (the “Organisation”) notified the Personal Data Protection Commission (the “Commission”) that an individual in its membership programme who had received an Electronic Direct Mail (“eDM”) from the Organisation, was able to access, without authentication, data in another individual’s account after clicking on a link (the “New eDM Link”) in the eDM (the “Incident”). Facts of the Case 2 The Organisation is a well-known consumer electronics and furniture retailer, with a number of stores in Singapore. Its membership programme, known as “homeclub by COURTS” (“Homeclub”) gives its members (“Members”) exclusive access to, among other things, events and discounts. The Organisation regularly sends eDMs to Members with links to specific products on the Organisation’s website (the “Website”). COURTS (Singapore) Pte Ltd 3 [2020] SGPDPC 17 The Organisation used a platform called Salesforce to create and send eDMs (the “Platform”) and the Website ran on the Magento system1 (the “System”), an e-commerce platform. The System generated a dynamic session identifier (“SID”) for each login to Homeclub on the Website. This SID would be used for all subsequent activities within the session. 4 On 31 August 2019, the Organisation sent an eDM to 76,844 Members (the “Affected Members”). This eDM, included for the first time, the New eDM Link, which was meant to direct Members to the Homeclub login page. The purpose of the New eDM Link was for Members to log in to their respective Homeclub accounts to update their membership identifier – Members were required to provide their mobile numbers to replace NRIC numbers that were previously used as the membership identifier. 5 The New eDM Link did not operate as intended, resulting in the Incident. The Commission’s investigations revealed the following: (a) Notwithstanding that the eDM sent on 31 August 2019 included for the first time the New eDM Link, the Organisation continued to use the System in its default setting. The default setting comprised (i) the SID embedded in the URL of the New eDM Link;2 and (ii) cookie settings to be refreshed after 60 minutes. (b) The default setting had not caused any issues when it was used by the Organisation to send marketing eDMs with eDM links directing Members to specific products on the Website. As Members were not 1 The Organisation acquired a license to operate the System from 6 March 2017. 2 This was due to the default setting “Use SID on Storefront” being set to “Yes” 2 COURTS (Singapore) Pte Ltd [2020] SGPDPC 17 required to log in to their accounts in order to view the specific products, the SID embedded in the URL and cookie settings did not affect the functioning of the Website. (c) However, the default setting should not have been used for the New eDM Link – it led to the System assuming that every use of the New eDM Link within 60 minutes of a Member’s login was part of the same session. This meant that: (i) If Member X clicks on the New eDM Link and logs into his Homeclub account without logging out within 60 minutes, all other Members who subsequently clicked on the New eDM Link within 60 minutes of Member X’s login would automatically be directed to Member X’s account, without having to authenticate their credentials; and (ii) If Member X logged out while other Members were still logged into Member X’s account, the other Members would only be logged out of Member X’s account if they refreshed a page or navigated to other pages within Member X’s account. 6 According to the Organisation, 128 of the Affected Members clicked on the New eDM Link between approximately 8am on 31 August 2019 and 12.25am on 1 September 2019.3 The Incident led to the risk of unauthorised access and modification of personal data in the Affected Members’ respective Homeclub accounts. In this regard, each Member’s Homeclub account 3 The eDM containing the New eDM Link was sent to Members at approximately 8am on 31 August 2019. The Organisation rectified the error causing the Incident at approximately 12.25am on 1 September 2019. 3 COURTS (Singapore) Pte Ltd [2020] SGPDPC 17 comprised (i) account information; and (ii) address book, which collectively contained the following data (“Personal Data Set”): (a) Name; (b) Email address: (c) Mobile Number; (d) Date of Birth (“DOB”); (e) Address; (f) Password; and (g) Transactional information i.e. products previously purchased by a Member. 7 In addition to unauthorised access, the following types of personal data in the Affected Members’ Personal Data Sets were at risk of unauthorised modification as a result of the Incident: (a) The Affected Member’s name, DOB, mobile number and residential address from his/her account information; and (b) The Affected Member’s name, mobile number and residential address from his/her address book. 8 The risk of unauthorised modification in [7(a)] and [7(b)] was possible because password verification was not required to make these changes. Conversely, an Affected Members’ username (which was his/her email address) and password could not be modified without password verification. An Affected Member’s Personal Data Sets also could not be downloaded by another Member 4 COURTS (Singapore) Pte Ltd [2020] SGPDPC 17 who had accessed his/her account because there was no download function on the Website. 9 There was no risk of financial loss to Affected Members through the Incident. While it was possible for another Member (who was given access to Member X’s account) to make a purchase through Member X’s account, he/she would have to provide credit card details to complete the purchase. This was because financial information (i.e. credit card details) was not stored in the System, and there was no reward system in Homeclub for the redemption of products or benefits. 10 Based on the Organisation’s investigations into the Incident, there was no evidence of any unauthorised modification to the Affected Members’ Personal Data Sets. Other than the Affected Member who had notified the Organisation of the Incident, the Organisation did not receive any further complaints or feedback. 11 Upon being notified of the Incident on the same day, the Organisation promptly took the following remedial actions: (a) Fixed the error that caused the Incident at approximately 12:25am on 1 September 2019 by changing the setting for “Use SID on Storefront” to “No”; (b) Implemented password verification for any changes to Members’ account information and address book;4 4 This came into effect on 6 January 2020. 5 COURTS (Singapore) Pte Ltd (c) [2020] SGPDPC 17 Put in place a standard operating procedure (“SOP”) to ensure correct link insertion into eDMs to protect personal data. For eDM links that are supposed to lead to a login page, checks will be conducted to ensure that there will be multiple concurrent user testing; (d) Took steps to engage an external vendor to work on security matters (including data protection security), and disseminate this information to its employees; and (e) Emailed the 128 Affected Members who had clicked on the New eDM Link to inform them of the Incident. The Commissioner’s Findings and Basis for Determination Whether the Organisation had contravened section 24 of the PDPA 12 Section 24 of the PDPA provides that an organisation shall protect personal data in its possession or under its control by making reasonable security arrangements to prevent unauthorised access, collection, use, disclosure, copying, modification or similar risks (the “Protection Obligation”). It is not disputed that the Organisation had possession and control of the Personal Data Sets at the material time. The Commission’s investigations revealed that the Organisation failed to put in place reasonable security arrangements to protect the Personal Data Sets for the reasons explained below. 13 First, the Organisation failed to conduct adequate testing before implementation. As mentioned at [4], this was the first time the Organisation included in its eDM, the New eDM Link to direct Members to the Homeclub login page. There was only 1 employee in the Organisation’s digital marketing team that was in charge of creating the New eDM Link and testing it prior to its 6 COURTS (Singapore) Pte Ltd [2020] SGPDPC 17 launch. The employee conducted a limited test of sending the eDM containing the New eDM Link to himself – the New eDM Link operated as intended, directing the employee to the Homeclub login page. This limited test was clearly inadequate. As emphasized in the Commission’s previous decisions, an organisation should ensure that testing scenarios are properly scoped. In particular, pre-launch testing of processes or systems needs to mimic expected real world usage, including foreseeable scenarios in a normal operating environment when the changes are introduced.5 In the present case, the Organisation intended to send the eDM to a very large number of Members. It is therefore foreseeable that testing scenarios should include multiple sequential logins or even concurrent logins to the Homeclub login page at peak usage. If the Organisation had tested the New eDM Link to approximate this real world scenario, the Incident would have likely come to light at that stage. 14 Second, the Organisation failed to assess the appropriateness of the default settings in the System for the New eDM Link. (a) The Organisation used the default setting in the System for the New eDM Link without any assessment on its implications. As mentioned in the Commission’s Guide to Securing Personal Data in Electronic Medium at [17.5] and previous decisions,6 when using readymade software, organisations are required to obtain a clear understanding of the intended purpose of the software, how the software 5 See Re Option Gift Pte Ltd [2019] SGPCPC 10 at [15]; Re AIA Singapore Pte Limited [2019] SGPDPC 20 at [15] and L’Oreal Singapore Pte. Ltd. Case No. DP 1812-B3091, Summary of the Decision at [3] 6 See for example Re DS Human Resource Pte Ltd [2019] SGPDPC 16 at [9] 7 COURTS (Singapore) Pte Ltd [2020] SGPDPC 17 functions and how to configure the software correctly. The Organisation failed to do so in the present case; (b) There was an option in the Platform to automatically generate eDM links without any SID in the URL. The Organisation did not fully appreciate the differences in using this option to create links that are embedded within an eDM, as compared with the effects of embedding SIDs as part of the URL for the New eDM Link. Due to the lack of understanding the differences between these out-of-the-box features of the commercial off-the-shelf product that he was using, the employee in charge of creating the New eDM Link was not aware that the appropriate method was to use the option in the Platform that generated eDM links without SID in the URL. Instead, the employee manually copied the New eDM Link (which contained the SID) from the internet browser for insertion into the eDM; and (c) While the Organisation had in place a process for a second-level check on the content and layout of the eDM, the nature of this type of checks would not have been effective in picking up the more technical issues relating to embedded SID in the New eDM Link. Understanding fully the features of the commercial off-the-shelf product in use and properly scoping the testing scenarios during user acceptance testing would have been the more appropriate and effective way to avoid and catch such errors. 15 For the reasons above, the Commissioner found the Organisation in breach of section 24 of the PDPA. 8 COURTS (Singapore) Pte Ltd [2020] SGPDPC 17 Representations by the Organisation 16 In the course of settling this decision, the Organisation made representations on the amount of financial penalty that the Commissioner intended to impose. The Organisation raised the following factors for the Commissioner’s consideration: (a) The Organisation takes a serious view of its obligations under the PDPA, and has taken the necessary remedial actions to prevent future data protection incidents from occurring. Personal data protection remains a priority for the Organisation even during these uncertain and turbulent times amidst the COVID-19 pandemic; and (b) The COVID-19 pandemic has had an adverse impact on the business of the Organisation, resulting in a significant loss of revenue. Specifically, due to “circuit breaker” measures imposed by the government, the Organisation closed all 14 of its retail outlets in Singapore from 7 April 2020 to 19 June 2020. Further, its operating overheads remained largely unchanged as labour accounted for significant portion of its costs, and the Organisation has maintained a commitment to retaining employees so as to protect their livelihoods. Even with the recent reopening of its physical stores, the Organisation continues to have a negative outlook of its business due to the impact of COVID-19 on the economy and a challenging retail landscape. 17 Having carefully considered the representations, the Commissioner has decided to reduce the financial penalty to the amount set out at [19]. The quantum of financial penalty has been calibrated after due consideration of the Organisation’s financial circumstances due to the unprecedented challenges faced by businesses amid the current Covid-19 pandemic, bearing in mind that 9 COURTS (Singapore) Pte Ltd [2020] SGPDPC 17 financial penalties imposed should not be crushing or cause undue hardship on organisations. Although a lower financial penalty has been imposed in this case, the quantum of financial penalty should be treated as exceptional and should not be taken as setting any precedent for future cases. The Commissioner’s Directions 18 In determining the directions, if any, to be imposed on the Organisation under Section 29 of the PDPA, the Commissioner took into account as an aggravating factor that this is the second time the Organisation has been found in breach of the Protection Obligation.7 The Commissioner also took into account the following mitigating factors: (a) The Organisation cooperated with the investigations and provided prompt responses to the Commission’s requests for information; (b) The Organisation implemented remedial actions swiftly to address the Incident; and (c) The Members’ Personal Data Sets was exposed to the risk of unauthorised access and/or modification for a limited period of less than one day. 19 Having considered all the relevant factors of this case, the Commissioner hereby directs the Organisation to pay a financial penalty of S$9,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 7 See Re Courts (Singapore) Pte Ltd [2019] SGPDPC 4 10 COURTS (Singapore) Pte Ltd [2020] SGPDPC 17 on the outstanding amount of the financial penalty until it is paid in full. The Commissioner has not set out any further directions given the remediation measures already put in place. YEONG ZEE KIN DEPUTY COMMISSIONER FOR COMMISSIONER FOR PERSONAL DATA PROTECTION 11 ",Financial Penalty,7b84d1c0b092675d5ee94570a80a3de93072541d,"[""tags"",""decision"",""pdf-url"",""description"",""date"",""timestamp"",""url"",""title"",""nature"",""pdf-content""]" 2023-10-01T11:02:10+08:00,fbd32491db44d3d0c97aa12a99cefd61ec954264,90,90,1,1016,A warning was issued to the Singapore Medical Association for failing to put in place reasonable security arrangements to prevent the unauthorised access of 68 individuals’ personal data which were forwarded to an external email address without authorisation.,"[""Protection"", ""Warning"", ""General (eg. Chamber of Commerce)"", ""Email forwarding"", ""Password policy""]",2020-09-10,https://www.pdpc.gov.sg/-/media/Files/PDPC/PDF-Files/Commissions-Decisions/Decision---Singapore-Medical-Association---21072020.pdf,Protection,Breach of the Protection Obligation by Singapore Medical Association,https://www.pdpc.gov.sg/all-commissions-decisions/2020/09/breach-of-the-protection-obligation-by-singapore-medical-association,2020-09-10,"PERSONAL DATA PROTECTION COMMISSION Case No. DP-2001- B5770 In the matter of an investigation under section 50(1) of the Personal Data Protection Act 2012 And Singapore Medical Association SUMMARY OF THE DECISION 1. On 31 January 2020, Singapore Medical Association (the “Organisation”) notified the Personal Data Protection Commission (the “Commission”) that the personal data of 68 individuals in 137 emails had been forwarded to an external email address without authorisation between 28 and 30 January 2020. The personal data comprised National Registration Identification Card numbers, dates of birth, indemnity coverage, period of coverage, educational information and financial transaction information. 2. The Organisation believed an unauthorised user (“UU”) gained entry into the affected Microsoft Office 365 email account by a brute force attack but did not have the system logs to confirm this. Regardless, the unauthorised entry enabled the UU to create an email rule to forward received emails to the external email address. 3. It was found that the Organisation failed to conduct periodic security reviews of its IT system. Consequently, it missed the opportunity to detect the following security issues that could have prevented the incident: a. There was no periodic change to the passwords of email accounts. As an example, the password to the affected account had not been changed since first use in November 2013. b. The Organisation collected financial information such as bank account details and swift codes and should have considered, as part of a security review, whether it needed to enhance security measures. For example, encryption of emails and/or attachments containing such sensitive personal data. c. A reasonable security review would also have noted the absence of security arrangements against brute force attacks. Common examples of anti-brute force measures include limiting the number of failed login attempts and account lockouts. Without anti-brute force measures, a password-protected account could be subjected to unlimited and uninterrupted automated login attempts from the Internet. Given sufficient time, the attacker will succeed in arriving at the correct password. 4. The Deputy Commissioner for Personal Data Protection therefore found that the Organisation did not adopt reasonable steps to protect personal data in its possession or under its control against risk of unauthorised access. The Organisation was in breach of the Protection Obligation under section 24 of the Personal Data Protection Act 2012. Upon consideration of the facts, a warning was issued to the Organisation. No directions are required as the Organisation had taken actions to address the gaps in its security arrangements. ",Warning,6c2d54a99a7623a26140ad101ee1ad4d4c2a792d,"[""tags"",""decision"",""pdf-url"",""description"",""date"",""timestamp"",""url"",""title"",""nature"",""pdf-content""]" 2023-10-01T11:02:10+08:00,fbd32491db44d3d0c97aa12a99cefd61ec954264,91,91,1,1016,"A financial penalty of $20,000 was imposed on Civil Service Club for failing to put in place reasonable security arrangements to protect its members’ personal data. A web directory containing members’ profile photographs and their respective NRIC/FIN numbers was found to be publicly accessible.","[""Protection"", ""Financial Penalty"", ""Arts, Entertainment and Recreation"", ""Access control"", ""Public access""]",2020-09-10,https://www.pdpc.gov.sg/-/media/Files/PDPC/PDF-Files/Commissions-Decisions/Decision---Civil-Service-Club-01042020.pdf,Protection,Breach of the Protection Obligation by Civil Service Club,https://www.pdpc.gov.sg/all-commissions-decisions/2020/09/breach-of-the-protection-obligation-by-civil-service-club,2020-09-10,"PERSONAL DATA PROTECTION COMMISSION [2020] SGPDPC 15 Case No DP-1907-B4180 In the matter of an investigation under section 50(1) of the Personal Data Protection Act 2012 And Civil Service Club … Organisation DECISION Civil Service Club [2020] SGPDPC 15 Tan Kiat How, Commissioner — Case No DP-1907-B4180 1 April 2020 Introduction 1 On 2 July 2019, the Personal Data Protection Commission (the “Commission”) received a complaint from a member (the “Complainant”) of the Civil Service Club (the “Organisation”). According to the Complainant, when he accessed his virtual membership card (the “Virtual Card”) through the Organisation’s membership web portal on the same day – “https://gateway.csc.sg” (the “Membership Portal”), he discovered that he was able to access a web directory – “https://gateway.csc.sg/webclub/facilities/tmp” (the “Directory”). The Directory contained profile photographs of other members (and their respective NRIC/FIN numbers which were used as file names for their profile photographs), including the Complainant’s (the “Incident”). Facts of the Case 2 The Organisation is a social club for all Public Service officers in Singapore, and also welcomes staff of Social Service Organisations and the general public to join as associate members. Membership benefits include booking of sports facilities, functions rooms and chalets, as well as members’ rates for club events and recreational activities. Civil Service Club 3 [2020] SGPDPC 15 In October 2009, the Organisation engaged the services of an IT vendor (the “Vendor”) to develop its Club Management System (“CMS”). The Vendor’s scope of work was set out in a contract entered into between the parties in November 2009 (the “Contract”). The Organisation launched the CMS, including the Membership Portal, in stages. On 1 March 2019, the Organisation launched the Virtual Card on the Membership Portal, and members’ NRIC/FIN numbers were used as file names for members’ profile photographs. 4 The Organisation has 2 separate servers hosted in its premises – the “enterprise” server (the “Enterprise Server”) and the “gateway” server (the “Gateway Server”). The Organisation stored its business and personal data on the Enterprise Server. The Gateway Server was specifically deployed to isolate the rest of the Organisation’s network (which may contain personal data or business data) from the public. 5 When a member accessed his/her Virtual Card, the software on the Membership Portal retrieved a copy of the member’s profile photograph from the Enterprise Server and stored it temporarily in the Directory. The Directory resided in the Gateway Server. The files in the Directory (including members’ profile photographs) were designed such that they could not be accessed by the public. If the member logged out from the Membership Portal, his/her profile photograph would be deleted from the Directory at that point in time. However, if the member closed the web browser directly without logging out of the Membership Portal, his/her profile photograph in the Directory would only be deleted during the monthly “housekeeping” process. Other than members’ profile photographs stored temporarily in the Directory (and their respective NRIC/FIN numbers which were used as file names for their profile photographs), the Gateway Server did not contain any other personal data. 2 Civil Service Club 6 [2020] SGPDPC 15 Prior to the Incident, there was an issue arising from members submitting their profile photographs in different file formats and sizes for the Virtual Card. The Vendor planned to monitor the situation for three months until 9 July 2019 and troubleshoot the issue during this period. 7 At first, the Vendor attempted to perform troubleshooting in a test environment using dummy photographs. However, the test environment could not replicate the issue with the Virtual Cards. In order to observe members’ behaviour patterns when they accessed their Virtual Cards and to collect statistics on photograph file sizes and time of creation, the Vendor enabled public access to the Directory on 3 occasions so that it could perform troubleshooting remotely. The Vendor also postponed the monthly “housekeeping"" process for the Directory by pushing it back from June 2019 to July 2019. 8 The Vendor only required a few minutes of remote access to perform remote troubleshooting, and had, as part of its testing procedures, a requirement that engineers restore all changes made during testing. On the first 2 occasions, public access to the Directory was disabled within 15 minutes. However, on 24 June 2019 (i.e. the 3rd occasion of remote troubleshooting), the Vendor’s engineer omitted to disable public access to the Directory but erroneously reported that he had done so. As a result, approximately 1,770 members’ profile photographs (and their respective NRIC/FIN numbers which were used as file names for their profile photographs) (the “Members Data”) could be accessed by anyone who obtained the URL to the Directory, including the Complainant on the date of the Incident. 9 Upon being notified of the Incident, the following remedial actions were taken: 3 Civil Service Club (a) [2020] SGPDPC 15 The Organisation and the Vendor took immediate action to disable access to the Directory; (b) The Vendor enhanced the “housekeeping” processes for the Directory such that the members’ profile photographs are deleted immediately after displaying them on the respective members’ Virtual Cards (i.e. there are no files containing members’ profile photographs stored in the Directory at any time); and (c) The Organisation discontinued the use of NRIC/FIN numbers as membership numbers, and the members’ profile photographs are no longer named using NRIC/FIN numbers. The Commissioner’s Findings and Basis for Determination Whether the Organisation had contravened section 24 of the PDPA 10 As a preliminary point, the Organisation owned the Enterprise Server and Gateway Server, and was in possession and control of the Members Data at all material times. While the Organisation had engaged the Vendor to develop the CMS, which included the Membership Portal, the scope of the Vendor’s work did not involve processing of any personal data on behalf of the Organisation. The Vendor was therefore not a data intermediary, and the responsibility to protect the Members Data fell squarely on the Organisation. 11 Section 24 of the Personal Data Protection Act 2012 (“PDPA”) provides that an organisation shall protect personal data in its possession or under its control by making reasonable security arrangements to prevent unauthorised access, collection, use, disclosure, copying, modification or similar risks (the “Protection Obligation”). The Organisation failed to put in place reasonable 4 Civil Service Club [2020] SGPDPC 15 security arrangements to protect the Members Data for the reasons explained below. 12 As mentioned at [3], the Organisation started engaging the Vendor’s services in October 2009. The Contract between the parties was entered into before the PDPA came into full force on 2 July 2014 (the “Appointed Day”). Before the Appointed Day, the Data Protection Provisions of the PDPA (i.e. Parts III to VI of the PDPA) were not in force, and the Organisation was not subject to these provisions in relation to personal data in its possession or control. However, after the Appointed Day, it became incumbent on the Organisation to take proactive steps to comply with the Data Protection Provisions of the PDPA in respect of the existing personal data held in its possession or control, as well as any new personal data that may come into its possession or control. It was not enough for the Organisation to leave matters status quo, if this would not enable it to meet the requirements and standards of the Protection Obligation.1 13 In the present case, the Commission’s investigations revealed that after the Appointed Day, the Organisation’s engagement of the Vendor’s services included work in relation to the developing and troubleshooting of the Virtual Cards on the Membership Portal. According to the Organisation, it was not aware that (i) Members Data had been stored temporarily in the Directory; and (ii) the Vendor’s troubleshooting involved enabling public access to the Directory. Notwithstanding this, given that the Organisation’s engagement of the Vendor’s services included work in relation to the Virtual Cards that contained Members Data, the Vendor (although not engaged to process the 1 See Re Social Metric Pte Ltd [2017] SGPDPC 17 at [10] – [11] 5 Civil Service Club [2020] SGPDPC 15 Members Data) may nevertheless handle the Members Data incidentally or make software system design decisions that affect the security of the Members Data in the course of providing its services. 14 In the circumstances, and in order for the Organisation to comply with the Protection Obligation, the Organisation should have ensured that it provided sufficient clarity and specifications on requirements to the Vendor (when developing and troubleshooting the CMS, Membership Portal and Virtual Cards) to protect the Members Data. There are various ways that the Organisation could have done so: (a) The Contract was entered into by the parties before the Appointed Day and did not contain any provisions on the protection of personal data.2 In view of the scope of services provided by the Vendor after the Appointed Day as set out at [13], the Organisation could have reviewed the Contract to include clauses setting out requirements for the Vendor to protect the Members Data. As highlighted in the Commission’s Guide on Building Websites for SMEs (revised 10 July 2018) at [4.2.1], organisations should emphasize the need for personal data protection to their IT vendors by making it part of their contractual terms. In this regard, the Organisation could have adapted relevant clauses from the Commission’s Guide on Data Protection Clauses for Agreements Relating to the Processing of Personal Data (published 20 July 2016) to suit the Organisation’s particular circumstances and needs. 2 The Contract contained only a confidentiality clause requiring each party to protect information identified by the other party as confidential. 6 Civil Service Club (b) [2020] SGPDPC 15 Further and/or in the alternative, the Organisation could have reviewed and revised the requirements specifications and software systems design documentation to include (i) requirements relating to how personal data (including the Members Data) should be handled as part of the design and layout the CMS and the Membership Portal;3 and (ii) technical and other measures that protect the personal data (including the Members Data). 15 From the Appointed Day, the Organisation’s failure to take any reasonable steps to ensure sufficient obligations are imposed on the Vendor (when developing and troubleshooting the CMS, Membership Portal and Virtual Cards) to protect the Members Data was a breach of its obligations under section 24 of the PDPA. A period of about five years had elapsed since 2 July 2014 to 2 July 2019. The Organisation, as owner of the CMS, should have included it as part of its personal data asset inventory and ensured that its data protection policies covered personal data held in the CMS. Had this been done, the Organisation would have identified these gaps in the business requirements for the CMS, which would have set it down the path to rectifying these gaps through one or both of the options discussed in the preceding paragraph. The Organisation, as owner of the CMS, is responsible for identifying the omission and articulating its business requirements relating to the protection of personal data stored in the CMS. This would have led to action by the Vendor in recommending technical fixes to enhance the CMS. It is the failure to identify the omission and articulate business requirements, and for a not-trivial period of five years, that is the gravamen of the Organisation’s breach of the PDPA. 3 See Commission’s Guide on Building Websites for SMEs (revised 10 July 2018) at [4.2.1] 7 Civil Service Club [2020] SGPDPC 15 The Commissioner’s Directions 16 In determining the directions, if any, to be imposed on the Organisation under Section 29 of the PDPA, the Commissioner took into account the following mitigating factors: (a) The Organisation cooperated with investigations; (b) There was limited risk to the Members Data arising from the Incident because (i) there was only one complaint received; and (ii) even if the Incident had not occurred, the Directory’s exposure to public access would have been discovered and rectified by 9 July 2019 because the Organisation and Vendor had planned to carry out a security audit on that date; and (c) The Organisation took prompt remedial action to rectify the Incident. 17 Having considered all the relevant factors of this case, the Commissioner directs the Organisation to pay a financial penalty of S$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 the financial penalty until it is paid in full. The Commissioner has not set out any further directions given the remediation measures already put in place. YEONG ZEE KIN DEPUTY COMMISSIONER FOR COMMISSIONER FOR PERSONAL DATA PROTECTION 8 ",Financial Penalty,f0321512ea7fdd1c3b0f5d62f673deb9411f9019,"[""tags"",""decision"",""pdf-url"",""description"",""date"",""timestamp"",""url"",""title"",""nature"",""pdf-content""]" 2023-10-01T11:02:10+08:00,fbd32491db44d3d0c97aa12a99cefd61ec954264,92,92,1,1016,"A financial penalty of $10,000 was imposed and a direction was issued to Grabcar for failing to put in place reasonable security arrangements to prevent the unauthorised access of GrabHitch drivers’ and passengers’ personal data via its mobile application.","[""Protection"", ""Financial Penalty"", ""Directions"", ""Transport and Storage"", ""Mobile application"", ""Code review""]",2020-09-10,https://www.pdpc.gov.sg/-/media/Files/PDPC/PDF-Files/Commissions-Decisions/Decision---Grabcar-Pte-Ltd---24072020.pdf,Protection,Breach of the Protection Obligation by Grabcar,https://www.pdpc.gov.sg/all-commissions-decisions/2020/09/breach-of-the-protection-obligation-by-grabcar,2020-09-10,"PERSONAL DATA PROTECTION COMMISSION [2020] SGPDPC 14 Case No. DP-1909-B4675 In the matter of an investigation under section 50(1) of the Personal Data Protection Act 2012 And Grabcar Pte Ltd … Organisation DECISION Grabcar Pte Ltd [2020] SGPDPC 14 Yeong Zee Kin, Deputy Commissioner — Case No. DP-1909-B4675 21 July 2020 Introduction 1 Grabcar Pte Ltd (the “Organisation”) is a Singapore-based company offering ride-hailing transport services, food delivery and digital payment solutions through its mobile application (the “Grab App”). The Grab App also provides a carpooling option referred to as “GrabHitch”. GrabHitch matches a passenger with a driver willing to give a lift to the passenger (on the way to the driver’s destination) in return for a fee. On 30 August 2019, the Organisation notified the Personal Data Protection Commission (the “Commission”) that, for a short period of time on the same day, profile data of 5,651 GrabHitch drivers was exposed to the risk of unauthorised access by other GrabHitch drivers through the Grab App (the “Incident”). Facts of the Case 2 The Organisation’s investigations traced the cause of the Incident to the deployment of an update to the Grab App on 30 August 2019 (the “ Update”). The purpose of the Update was to address a potential vulnerability discovered within the Grab App, namely, the application programming interface (“API”) endpoint (/users/{userID}/profile) (the “URL”) that had allowed GrabHitch Grabcar Pte Ltd [2020] SGPDPC 14 drivers to access their data, contained a ‘userID’ that could potentially be manipulated to allow access to other GrabHitch driver’s data.1 3 In order to fix the vulnerability, the Update removed the variable ‘userID’ from the URL which shortened it to a hard-coded ‘/users/profile’. However, the Update failed to take into account the URL-based caching mechanism in the Grab App. This caching mechanism (which was configured to refresh every 10 seconds) served cached content in response to data requests to reduce the load of direct access to the Organisation’s database. 4 With the deployment of the Update, all URLs in the Grab App ended with “/users/profile”. Without the variable ‘userID’ in the URL (which directed data requests to the correct GrabHitch driver’s accounts), the caching mechanism could no longer differentiate between GrabHitch drivers. Consequentially, the caching mechanism provided the same data to all GrabHitch drivers for 10 seconds before new data was retrieved from the Organisation’s database and cached for the next 10 seconds. 5 As a result of the Incident, a total of 21,541 GrabHitch drivers’ and passengers data was exposed to the risk of unauthorised access (collectively “Personal Data Sets”): (a) Profile pictures; (b) Passenger names; (c) Vehicle plate number; and 1 According to the Organisation, there was no evidence that this vulnerability had been exploited. 2 Grabcar Pte Ltd (d) 6 [2020] SGPDPC 14 Wallet balance comprising journal history of ride payments. In addition to the Personal Data Sets, other data that was exposed to the risk of unauthorised access during the Incident included GrabHitch booking details such as addresses and pickup and drop-off times; and driver details such as total rides, vehicle model and make. 7 Upon being notified of the Incident, the Organisation took the following remedial actions: (a) Rolled back the Grab App to the version prior to the Update within approximately 40 minutes; (b) Notified 5,651 GrabHitch drivers of the Incident on the same day; 2 (c) Increased the minimum “cash out” amount for wallets in GrabHitch to S$200,000 to prevent unauthorised transfers; (d) Deployed a new update for the Grab App on 10 September 2019; (e) Reviewed its testing procedures including implementing mandatory automated tests for all API endpoints dealing with personal data; (f) Updated governance procedures concerning deployment and security verification on changes to IT systems and applications; and 2 The Organisation’s initial investigations indicated that 5,651 GrabHitch drivers’ data was exposed to the risk of unauthorised access due to the Incident. Following further investigations, the Organisation determined that up to 21,541 GrabHitch drivers’ and passengers data was exposed to the risk of unauthorised access. 3 Grabcar Pte Ltd (g) [2020] SGPDPC 14 Embarked on an architecture review of its legacy applications, and relevant codes which had not been reviewed for an extended period of time. The Commissioner’s Findings and Basis for Determination Whether the Organisation had contravened section 24 of the PDPA 8 Section 24 of the Personal Data Protection Act 2012 (“PDPA”) provides that an organisation shall protect personal data in its possession or under its control by making reasonable security arrangements to prevent unauthorised access, collection, use, disclosure, copying, modification or similar risks. It is not disputed that the Organisation had possession and control of the Personal Data Sets at the material time. 9 In the context of the present case, given that the Organisation made changes to its IT system that processed the Personal Data Sets, it is obliged to put in place reasonable security arrangements to prevent any compromise to the Personal Data Sets.3 The Organisation failed to do so for the reasons explained below. 10 First, the Organisation did not put in place sufficiently robust processes to manage changes to its IT system that may put the personal data it was processing at risk. This was a particularly grave error given that this is the 3 Re Flight Raja Travels Singapore Pte Ltd [2018] SGPDPC 16 at [8]. 4 Grabcar Pte Ltd [2020] SGPDPC 14 second time the Organisation is making a similar mistake, albeit with respect to a different system.4 (a) The Organisation introduced changes to the Grab App (through the Update) without understanding how the changes would operate with existing features of the Grab App and its broader IT system, including the caching mechanism. (b) In particular, the Update involved changes to the URL (i.e. removing the variable ‘userID’). The variable ‘userID’ in the URL had the function of ensuring that data requests (including the Personal Data Sets) were directed to the correct GrabHitch drivers’ accounts. However, the Organisation implemented the Update without making an assessment whether the Grab App would continue to direct data requests to the correct GrabHitch drivers’ accounts without the variable ‘userID’ in the URL. 11 Second, the Organisation did not conduct properly scoped testing before the Update to the Grab App was deployed. (a) As found in the Commission’s previous decisions, organisations are obliged to conduct properly scoped testing before new IT features or changes to IT systems are deployed. These tests need to mimic real world usage, including foreseeable scenarios in a normal operating 4 See Re Grabcar Pte Ltd [2019] SGPDPC 15 at [17] where it was found that the Organisation did not have adequate measures in place to detect whether the changes it made to a system that held personal data introduced errors that put the personal data it was processing at risk. 5 Grabcar Pte Ltd [2020] SGPDPC 14 environment when the changes are introduced.5 Such tests prior to deployment are critical to enable organisations to detect and rectify errors in the new IT features and/or be alerted to any unintended effects from changes that may put personal data at risk.6 (b) In the present case, the Organisation admitted that it did not conduct tests to simulate multiple users accessing the Grab App, whether concurrently or consecutively. The Organisation also admitted that it did not conduct any specific test to verify how the caching mechanism would work in tandem with the Update. (c) In view of the large number of GrabHitch drivers, multiple users logging in concurrently or consecutively are foreseeable scenarios that the Organisation should have simulated during its testing of the Update prior to deployment. Properly scoped pre-launch tests would have included an assessment of how the caching mechanism may affect the intended operation of the Update because the caching mechanism can affect data requests returned to the GrabHitch drivers. 12 For the reasons above, I find the Organisation in breach of section 24 of the PDPA. 5 Re AIA Singapore Pte Limited [2019] SGPDPC 20 at [15] and L’Oreal Singapore Pte. Ltd. Case No. DP 1812-B3091, Summary of the Decision at [3]. 6 See for example Re Flight Raja Travels Singapore Pte Ltd [2018] SGPDPC 16 and Re Singapore Telecommunications Limited [2019] SGPDPC 36. 6 Grabcar Pte Ltd [2020] SGPDPC 14 The Deputy Commissioner’s Directions 13 In determining the directions, if any, to be imposed on the Organisation under Section 29 of the PDPA, I took into account as a mitigating factor that the Organisation cooperated with the investigation, and was prompt and forthcoming in its response to queries during the Commission’s investigations. I have also taken into consideration that this is the fourth time the Organisation has been found in breach of Section 24 of the PDPA. 7 Given that the Organisation’s business involves processing large volumes of personal data on a daily basis, this is a significant cause for concern. 14 Having considered all the relevant factors of this case, I direct the Organisation to pay a financial penalty of S$10,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 the financial penalty until it is paid in full. In order to reduce the risk of another data breach, I also direct the Organisation to put in place a data protection by design policy for its mobile applications within 120 days of the date of this direction. YEONG ZEE KIN DEPUTY COMMISSIONER FOR PERSONAL DATA PROTECTION 7 The previous decisions being Re Grabcar Pte Ltd [2018] SGPDPC 23; Re Grabcar Pte Ltd [2019] SGPDPC 14; and Re Grabcar Pte Ltd [2019] SGPDPC 15. 7 ","Financial Penalty, Directions",eb17aef1e75850888d8ec821aa37aebe142109b2,"[""tags"",""decision"",""pdf-url"",""description"",""date"",""timestamp"",""url"",""title"",""nature"",""pdf-content""]" 2023-10-01T11:02:10+08:00,fbd32491db44d3d0c97aa12a99cefd61ec954264,93,93,1,1016,Singtel was found not in breach for failing to make reasonable security arrangements to prevent the unauthorised access of its customers’ personal data via the mySingtel mobile application.,"[""Not in Breach"", ""Others"", ""No breach"", ""Mobile application"", ""Singtel""]",2020-09-10,https://www.pdpc.gov.sg/-/media/Files/PDPC/PDF-Files/Commissions-Decisions/Decision---Singapore-Telecommunications-Limited---05082020.pdf,,No Breach of the Protection Obligation by Singtel,https://www.pdpc.gov.sg/all-commissions-decisions/2020/09/no-breach-of-the-protection-obligation-by-singtel,2020-09-10,"PERSONAL DATA PROTECTION COMMISSION [2020] SGPDPC 13 Case No. DP-1904-B3731 In the matter of an investigation under section 50(1) of the Personal Data Protection Act 2012 And Singapore Telecommunications Limited … Organisation DECISION Singapore Telecommunications Limited [2020] SGPDPC 13 Yeong Zee Kin, Deputy Commissioner — Case No. DP-1904-B3731 5 August 2020 Introduction 1 On 28 March 2019, Singapore Telecommunications Limited (the “Organisation”) was notified by a customer of an issue with its MySingtel mobile application (the “Mobile App”) – customers were able to view on the Mobile App their previously assigned service numbers 1 (the “Recycled Numbers”) and the related usage information of other customers who were the current users of the Recycled Numbers (the “Incident”). The Organisation notified the Personal Data Protection Commission (the “Commission”) of the Incident on 17 April 2019. Facts of the Case 2 The Organisation is a multinational telecommunications conglomerate headquartered in Singapore. Through the Mobile App, the Organisation’s customers can conveniently manage the Organisation’s services including (but service numbers comprised mobile phone numbers, user IDs for the Organisation’s broadband internet services and service numbers for the Organisation’s TV services. 1 The Singapore Telecommunications Limited [2020] SGPDPC 13 not limited to) the payment of their bills, keeping track of their local mobile data usage, talk time and SMS, subscribing to a roaming plan to suit their travel needs etc. Communications between the Mobile App and the Organisation’s servers are conducted via an Application Programming Interface (“API”). This would include the retrieval of active service numbers associated with a user of the Mobile App. 3 The Organisation engaged a software services provider who was in charge of developing and introducing code changes for the purpose of code updates to the API (the “Vendor”). As part of a scheduled code update on the day of the Incident, the Vendor made changes to the API code. In addition, the Vendor also conducted code optimisation by running a tool called SonarQube, which identifies and recommends inefficient code for removal. On this particular occasion, SonarQube recommended the removal of the code which governed the condition that decoupled Recycled Numbers from their previous users (the “Condition”). The Vendor followed SonarQube’s recommendation and removed the Condition. 4 Before the code changes were deployed to production, the Vendor raised a Technical Change Request form (“TCR”) to notify the Organisation of the changes made. However, the Vendor omitted to report the removal of the Condition in the TCR submitted to the Organisation. 5 Prior to accepting the code changes to the API for deployment, the Organisation conducted business user acceptance testing for business needs and regression testing for existing functionality. Given that this was a scheduled code update, these tests were limited in scope to the changes reported in the TCR. As the removal of the Condition was not reported in the TCR, the Organisation was unaware of this change, and did not conduct testing on the 2 Singapore Telecommunications Limited [2020] SGPDPC 13 impact to the operation of the Mobile App due to removal of the Condition. Following the pre-launch testing, the code changes were approved by the Organisation for deployment. 6 The removal of the Condition led to the API retrieving both active and Recycled Numbers associated with a user of the Mobile App, resulting in the Incident. According to the Organisation, 384 of its customers were affected by the Incident (the “Affected Individuals”). The following types of personal data of the Affected Individuals’ that was at risk of unauthorised access through the Mobile App included (collectively, the “Personal Data Sets”): (a) Recycled Numbers2; (b) Installation addresses of those Affected Individuals who subscribed to the Organisation’s broadband and TV services; (c) Usage details including mobile phone talk time, number of text messages sent and amount of mobile data used; (d) Value-added services subscribed to; (e) Price plans of the various services subscribed to; and (f) Billing cycles for the Recycled Numbers. 2 There was a total of 404 unique Recycled Numbers belonging to the Affected Individuals. 3 Singapore Telecommunications Limited 7 [2020] SGPDPC 13 Upon being notified of the Incident, the Organisation promptly carried out the following actions to mitigate the effects of the Incident: (a) Blocked access to the Mobile App a few hours after being notified of the Incident; (b) Implemented a fix for the Mobile App the day after the Incident, and restored access to the Mobile App; and (c) Reversed five erroneous transactions relating to roaming and callerID that were processed during the Incident. 8 In addition, to prevent a recurrence of the Incident or similar risks: (a) The Organisation will be implementing additional regression test scenarios which will cover testing of Recycled Numbers; (b) The Organisation has also implemented the following enhancements on the Mobile App: (i) To prevent any historical services from being retrieved and displayed on the Mobile App, only active services will be displayed moving forward; and (ii) Enhanced the Mobile App to ensure that only information retrieved for the customer’s identifiers in the authenticated session is displayed on the Mobile App. Findings and Basis for Determination 9 As a preliminary point, the Organisation owned the Mobile App and was in possession and control of the Personal Data Sets. The Vendor’s role, in the context of the Incident, was to develop and introduce code changes to the API 4 Singapore Telecommunications Limited [2020] SGPDPC 13 for the purposes of the code update. The Vendor did not process the Personal Data Sets on behalf of the organisation and was accordingly not a data intermediary. In the circumstances, the responsibility to protect the Personal Data Sets fell squarely on the Organisation. 10 Section 24 of the Personal Data Protection Act 2012 (the “PDPA”) provides that an organisation shall protect personal data in its possession or under its control by making reasonable security arrangements to prevent unauthorised access, collection, use, disclosure, copying, modification or similar risks (the “Protection Obligation”). 11 As highlighted in previous decisions 3, an organisation is not required to provide an absolute guarantee for the protection of personal data in its possession. What is expected of the organisation is to make such security arrangements as a reasonable person would consider appropriate, given the nature of the personal data involved and the particular circumstances of the Organisation. The Protection Obligation is not automatically breached upon the occurrence of a data leak, and this case is an example of an application of this principle. 12 The Commission’s investigations revealed that the security arrangements put in place by the Organisation to protect the Personal Data Sets was reasonable in the circumstances for the reasons explained below. 3Re Tiger Airways Singapore Pte Ltd [2017] SGPDPC 6 and Re BHG (Singapore) Pte Ltd [2017] SGPDPC 16. 5 Singapore Telecommunications Limited (a) [2020] SGPDPC 13 First, the Organisation emphasized to the Vendor the need for personal data protection of the Organisation’s customers by making it part of the contractual terms in the Statement of Works 4. Specifically, the Statement of Works contained data protection clauses requiring the Vendor to establish security processes and actively enforce policies addressing personal data protection, follow industry standard measures to protect the Organisation’s customers’ personal data, and exercise the same degree of care to guard against unauthorised disclosure. In addition, the Organisation verified the data protection arrangements put in place by the Vendor to protect its customers’ data5. This included conducting audits on the Vendor to ensure the adequacy and effectiveness of IT controls and processes implemented by the Vendor, and to ensure that the Vendor’s staff conformed to the said IT controls and processes. Further, in order to increase its vendors’ knowledge and awareness of the PDPA’s requirements, the Organisation also conducted mandatory annual briefings for its vendors on the PDPA, the Organisation’s cybersecurity policy for third party vendors as well as information security. These annual briefings were attended by the Vendor’s employees. 4 Commission’s Guide on Building Websites for SMEs (revised 10 July 2018) at [4.2.1]. 5cf. Re SCAL Academy Pte Ltd [2020] SGPDPC 2 at [8]: Organisation instructed its vendor to prevent documents from being “leaked” online, but did not check with its vendor what security arrangements were put in place to ensure this. 6 Singapore Telecommunications Limited (b) [2020] SGPDPC 13 Second, the Organisation ensured that the pre-launch tests for code changes were reasonably scoped to pick up and rectify errors and/or flaws prior to deployment. (i) The Organisation had conducted business user acceptance testing based on the change requests set out by the Vendor in the TCR. As mentioned at [5], there was no testing conducted on the impact to the operation of the Mobile App due to removal of the Condition – the Organisation was not aware of the removal of the Condition because it had not been reported in the TCR. Given that there was no reason for the Organisation to suspect any additional code changes in a scheduled routine code update, it was reasonable for the Organisation to perform testing only on those changes set out in the TCR 6. (ii) As part of its quality assurance measures, the Organisation conducted various testing of critical business functions of the Mobile App, including user acceptance testing and regression testing. The results from the tests were reviewed by directors in the Organisation’s business and IT departments before the code changes were approved for deployment to the Mobile App. 6cf: The Commission’s previous decisions where organisations were found in breach of Section 24 of the PDPA for not conducting sufficiently scoped pre-launch tests before introducing new changes to its systems that processed personal data. See for example: Re Flight Raja Travels Singapore Pte Ltd [2018] SGPDPC 18 (organisation introduced a new mobile application) and Re Singapore Telecommunications Limited [2019] SGPDPC 49 (organisation migrated its database of customer accounts to a new billing system). 7 Singapore Telecommunications Limited 13 [2020] SGPDPC 13 In conclusion, nothing in the Commission’s investigations pointed to the cause of the Incident being due to a systemic problem in the Organisation’s measures to protect the Personal Data Sets. Instead, this appeared to be a oneoff incident that was difficult to foresee in the circumstances. Having carefully considered all the relevant circumstances and for the reasons set out above, I find that the Organisation had not contravened its obligations under section 24 of the PDPA. YEONG ZEE KIN DEPUTY COMMISSIONER FOR PERSONAL DATA PROTECTION 8 ",Not in Breach,cf1510a1a435f6eb0468b1dd403f3cf6c72407a6,"[""tags"",""decision"",""pdf-url"",""description"",""date"",""timestamp"",""url"",""title"",""nature"",""pdf-content""]" 2023-10-01T11:02:10+08:00,fbd32491db44d3d0c97aa12a99cefd61ec954264,94,94,1,1016,"A financial penalty of $5,000 was imposed on Singapore Red Cross for breaches of the PDPA. First, the Organisation failed to put in place reasonable security arrangements to protect the personal data of its blood donors. Second, it was also found to be retaining personal data which was no longer necessary for legal or business purposes.","[""Protection"", ""Financial Penalty"", ""Social Service"", ""Security"", ""Retention""]",2020-09-10,https://www.pdpc.gov.sg/-/media/Files/PDPC/PDF-Files/Commissions-Decisions/Decision---Singapore-Red-Cross---05052020.pdf,Protection,Breach of the Protection and Retention Limitation Obligations by Singapore Red Cross,https://www.pdpc.gov.sg/all-commissions-decisions/2020/09/breach-of-the-protection-and-retention-limitation-obligations-by-singapore-red-cross,2020-09-10,"PERSONAL DATA PROTECTION COMMISSION [2020] SGPDPC 16 Case No DP-1905-B3865 In the matter of an investigation under section 50(1) of the Personal Data Protection Act 2012 And Singapore Red Cross Society … Organisation DECISION Singapore Red Cross Society [2020] SGPDPC 16 Singapore Red Cross Society [2020] SGPDPC 16 Tan Kiat How, Commissioner — Case No DP-1905-B3865 5 May 2020 Facts of the Case 1 Singapore Red Cross Society (the “Organisation”) operates a website at http://www.redcross.sg (the “Website”) which allows the public to make appointments for blood donations. For this purpose, the Organisation collects personal data of individuals such as their names, contact numbers, email addresses and blood types (the “Personal Data”). The Personal Data was stored in the Organisation’s blood donor appointment database (the “Database”) accessible via the Website. 2 On 9 May 2019, the Organisation notified the Personal Data Protection Commission (the “Commission”) that unauthorised individual(s) accessed and ex-filtrated the Personal Data of approximately 4,297 individuals (“Affected Individuals”) from the Database (the “Incident”). 3 Upon being notified of the Incident, the Organisation took the following remedial actions: (a) Removed the appointment booking system on its Website in order to temporarily cease its collection of Personal Data through that channel; and (b) Revised and strengthened its internal procedures to comply with the PDPA. 1 Singapore Red Cross Society [2020] SGPDPC 16 The Commissioner’s Findings and Basis for Determination The Organisation admitted that it had contravened Section 24 of the PDPA 4 Section 24 of the Personal Data Protection Act 2012 (“PDPA”) provides that an organisation shall protect personal data in its possession or under its control by making reasonable security arrangements to prevent unauthorised access, collection, use, disclosure, copying, modification or similar risks (the “Protection Obligation”). 5 The Organisation admitted that it failed to implement adequate security measures to protect the Personal Data stored in the Database, and had breached the Protection Obligation. In particular, the Organisation admitted to the following specific mistakes: (a) The Organisation employed a vendor to develop the Website. However, there was a lack of supervision over the vendor’s work which led to a failure to detect the presence of a phpMyAdmin database administration tool (the “Tool”) which was used to manage the Database. There was also no password management policy requiring strong passwords of sufficient length and complexity during the development phase. This resulted in a weak password (i.e. “12345”) being set for the Tool;1 and (b) The Organisation did not conduct any regular security reviews, e.g. vulnerability assessment, on its systems that would identify applications that it did not need. 2 Consequentially, the Organisation did not realise that the Tool remained connected to the Website even after development of the Website had been completed. This allowed unauthorised individual(s) to gain access to the Database through the Tool which had a weak password. 1 For examples of the Commission’s previous decisions on the need for proper password management policies, see Re Orchard Turn Developments Pte Ltd [2017] SGPDPC 12 at [35] – [36] and Re Spize Concepts Pte Ltd [2019] SGPDPC 22 at [15]. 2 For examples of the Commission’s previous decisions on the requirement for periodic security reviews, see Re Watami Food Services Singapore Pte Ltd [2018] SGPDPC 12 at [6]; Re WTS Automotive Services [2018] SGPDPC 26 at [18]; Re Bud Cosmetics [2019] SGPDPC 1 at [24]; Re Chizzle Pte Ltd [2019] SGPDPC 44 at [6]. 2 Singapore Red Cross Society [2020] SGPDPC 16 The Organisation admitted that it had contravened Section 25 of the PDPA 6 Under Section 25 of the PDPA, an organisation is obliged 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 reasonable to assume that: (a) the purpose for which the personal data was collected is no longer served by retaining the data; and (b) the retention is no longer necessary for legal or business purposes (the “Retention Limitation Obligation”). 7 The Organisation admitted that there had been unnecessary retention of Personal Data of approximately 900 Affected Individuals, and this was a breach of the Retention Limitation Obligation. (a) Prior to the Incident, the Organisation intended to purge Personal Data of these 900 Affected Individuals from the Database. However, the Organisation provided wrong instructions to its vendor for the purging exercise. The Organisation had instructed its vendor to only remove some data elements instead of entire records of the 900 Affected Individuals’ Personal Data; and (b) The Organisation also did not conduct any verification checks to ensure the purging exercise was properly carried out. As a result, the Organisation failed to detect that the Database still retained records of the 900 Affected Individual’s Personal Data. 8 In view of the above, the Commissioner found the Organisation in breach of sections 24 and 25 of the PDPA. The Organisation’s Representations 9 In the course of settling this decision, the Organisation made representations on the amount of financial penalty that the Commissioner intended to impose. The Organisation raised the following factors for the Commissioner’s consideration: 3 Singapore Red Cross Society (a) [2020] SGPDPC 16 The Organisation is a charity that depends on public donations to run its operations and programmes, all which are for the benefit of the community. Such a high financial penalty would set the Organisation back significantly, and would mean less help for the disadvantaged and the vulnerable; (b) The Organisation takes its obligations under the PDPA seriously and already had in place various IT security measures and had embarked on a consultancy to ensure its compliance with the PDPA even before the Incident; (c) The attackers were skilled hackers who utilised sophisticated hacking tools to exploit a weak administrator password for the Tool which left the Database vulnerable to unauthorised access. The Tool was never used by the Organisation’s staff and was likely created during the development stage of Database; (d) Upon being informed of the Incident, the Organisation immediately made a police report and promptly informed various public authorities including the Health Sciences Authority and the Commission. The Organisation has also extended full cooperation and provided prompt responses during the Commission’s investigations; (e) The Organisation promptly informed all affected individuals and there were no registered complaints on the case; (f) Since the Incident, the Organisation had taken immediate steps to remove the Database from the Website and put in place more security measures. This included layered and restricted access, isolation of sensitive systems at the network level, password training for staff, review and strengthening of standard operating procedures, practising more stringent oversight of vendor actions, implementation of vulnerability assessment and penetration testing regime for critical systems before deployment and on a regular basis annually; and (g) The financial penalty that the Commissioner intended to impose seemed excessive in light of previous decisions for similar or even more serious breaches. 4 Singapore Red Cross Society 10 [2020] SGPDPC 16 With respect to the representations on the nature and purpose of the Organisation, the fact that the Organisation is a charity cannot be a mitigating factor, and its charitable status cannot lower the standard expected of it in complying with its obligations under the PDPA. The admitted failures on the Organisation’s part at [5] clearly fell short of the standard of protection required for the Personal Data stored in the Database. 11 As for the Organisation’s representations comparing the present case to previous decisions, it needs only to be said that each decision is based on the unique facts of each case. The decision in each case takes into consideration the specific facts of the case so as to ensure that the decision and direction(s) are fair and appropriate for that particular organisation. The Commissioner’s Directions 12 Having carefully considered the representations, the Commissioner has decided to reduce the financial penalty to the amount set out at [13]. The quantum of financial penalty has been determined after due consideration of the appropriate weight to be given to: (a) the Organisation’s upfront voluntary admission of liability which significantly reduced the time and resources required for investigations under the Expedited Breach Decision procedure;3 and (b) the Organisation’s comprehensive remedial actions at [9(f)] to address the inadequacies in its procedures and processes that contributed to the Incident. 13. Taking into account all the relevant facts and circumstances, the Commissioner directs the Organisation to pay a financial penalty of $5,000 within 30 days from the date of the 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 the financial penalty is paid in full. Although a lower financial 3 See the Commission’s Guide on Active Enforcement at page 21 5 Singapore Red Cross Society [2020] SGPDPC 16 penalty has been imposed in this case, this is exceptional and should not be taken as setting any precedent for future cases. 14. In view of the remedial measures taken by the Organisation, the Commissioner has not imposed any other directions. YEONG ZEE KIN DEPUTY COMMISSIONER FOR COMMISSIONER FOR PERSONAL DATA PROTECTION 6 ",Financial Penalty,7bdf02b93a7a9d9facf04ceb3c80a66892a08642,"[""tags"",""decision"",""pdf-url"",""description"",""date"",""timestamp"",""url"",""title"",""nature"",""pdf-content""]" 2023-10-01T11:02:10+08:00,fbd32491db44d3d0c97aa12a99cefd61ec954264,95,95,1,1016,"A financial penalty of $5,000 was imposed on Singapore Accountancy Commission for failing to put in place reasonable security arrangements to prevent the unauthorised access of 6,541 Singapore Chartered Accountant Qualification programme personnel and candidates’ personal data.","[""Protection"", ""Financial Penalty"", ""Professional"", ""Scientific and Technical"", ""Unintended recipient"", ""Email attachments""]",2020-08-03,https://www.pdpc.gov.sg/-/media/Files/PDPC/PDF-Files/Commissions-Decisions/Decision---Singapore-Accountancy-Commission---22062020.pdf,Protection,Breach of the Protection Obligation by Singapore Accountancy Commission,https://www.pdpc.gov.sg/all-commissions-decisions/2020/08/breach-of-the-protection-obligation-by-singapore-accountancy-commission,2020-08-03,"PERSONAL DATA PROTECTION COMMISSION Case No. DP-1911-B5296 In the matter of an investigation under section 50(1) of the Personal Data Protection Act 2012 And Singapore Accountancy Commission SUMMARY OF THE DECISION 1. On 18 November 2019, Singapore Accountancy Commission (the “Organisation”) notified the Personal Data Protection Commission (the “Commission”) that a folder containing personal data of 6,541 Singapore Chartered Accountant Qualification programme personnel and candidates was mistakenly enclosed in emails sent to 41 unintended recipients between 12 June 2019 and 22 October 2019. The folder comprised information such as names, National Registration Identification Card numbers, dates of birth, contact details, education and employment information and Singapore Chartered Accountant Qualification examination results. Following the incident, 41 unintended recipients confirmed deletion of the email and folder they each received. 2. The Organisation admitted to a lack of robust processes to protect personal data when sending emails. The staff involved in the sending of the emails were not informed of the Organisation’s personal data policies as part of their induction training. The Organisation’s data protection policies and procedures were not translated into security arrangements for protection of personal data. There were, for example, no second-tier or supervisory checks or technical measures to reduce the risk of sending content with personal data to unintended parties at the time of the incident. 3. Following the incident, the Organisation undertook remediation. This included training sessions on cybersecurity and personal data protection for all employees and revision of policies and procedures on handling of personal data. 4. In the circumstances, the Deputy Commissioner for Personal Data Protection found that the Organisation did not adopt reasonable steps to protect personal data in its possession or under its control against unauthorised access. The Organisation was in breach of the Protection Obligation under section 24 of the Personal Data Protection Act 2012 (the “PDPA”). 5. The Organisation had made an admission of breach of the Protection Obligation under the PDPA, cooperated with the Commission’s investigation and taken prompt remedial actions. 6. On account of the above, the Organisation is directed 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. In view of the remedial actions taken by the Organisation, the Commission will not issue any other directions. ",Financial Penalty,3a8e7894f9d69623906f336fc824af00e156f58e,"[""tags"",""decision"",""pdf-url"",""description"",""date"",""timestamp"",""url"",""title"",""nature"",""pdf-content""]" 2023-10-01T11:02:10+08:00,fbd32491db44d3d0c97aa12a99cefd61ec954264,96,96,1,1016,A warning was issued to Zero1 and IP Tribe respectively for failing to put in place reasonable security arrangements to prevent the unauthorised disclosure of 118 individuals’ personal data contained in invoices which were sent to incorrect recipients.,"[""Protection"", ""Warning"", ""Information and Communications"", ""Unintended recipient"", ""Duplication of batch ID"", ""Inadequate scoping of testing""]",2020-08-03,https://www.pdpc.gov.sg/-/media/Files/PDPC/PDF-Files/Commissions-Decisions/Decision---Zero1-and-IP-Tribe---07042020.pdf,Protection,Breach of the Protection Obligation by Zero1 and IP Tribe,https://www.pdpc.gov.sg/all-commissions-decisions/2020/08/breach-of-the-protection-obligation-by-zero1-and-ip-tribe,2020-08-03,"PERSONAL DATA PROTECTION COMMISSION Case Nos. DP-1903-B3630, DP-1908-B4431 In the matter of an investigation under section 50(1) of the Personal Data Protection Act 2012 And 1. Zero1 Pte. Ltd. 2. IP Tribe Pte Ltd SUMMARY OF THE DECISION 1. On 22 March 2019, Zero1 Pte Ltd (the “Organisation”) voluntarily informed the Personal Data Protection Commission (the “Commission”) that invoices containing the personal data of their subscribers had been emailed to unintended recipients (the “Incident”). Each invoice contained the name, address, subscriber ID, mobile number, mobile charges, and the call details of any international calls made by a subscriber (the “Personal Data”). Each email contained a subscriber’s invoice which was unintendedly sent to another subscriber instead. 2. The Organisation was a licensed Mobile Virtual Network Operation that provided mobile services. It partnered Singtel Mobile Singapore Pte. Ltd. (“Singtel”), which appointed IP Tribe Pte Ltd (“IPT”) to develop and deploy a Mobile Virtual Network Enabler (the “1st Platform”) to manage subscriber accounts. 3. IPT ran the 1st Platform for the Organisation, including generating and sending monthly emails to subscribers. IPT then subcontracted the provision of the billing system within the 1st Platform to Openet Telecom Sales Limited (“Openet”). The 1st Platform was deployed in August 2018. 4. A replacement platform (the “New Platform”) was deployed in 2019. Openet subcontracted 6D Technologies (“6D”) to migrate subscriber data from the 1st Platform to the New Platform. In February 2019, 6D migrated the data of 12,000 to 15,000 subscribers. 5. The Incident was caused by Batch ID duplication. The Batch ID was a unique number that tagged each subscriber to his name and email address. The migration was staggered and some errors made it necessary to delete data migrated earlier. However, due to a coding error, not all previously migrated data had been deleted. The New Platform failed to recognise the Batch IDs that were not deleted and re-issued the same Batch IDs. As a result, 118 invoices belonging to subscribers with duplicated Batch IDs were affected. Since each Batch ID determined the email address to which an invoice was sent, Batch ID duplication resulted in the New Platform emailing the 118 invoices to the wrong addresses. 6. Before a new IT system or a change to an IT system goes live, pre-launch testing is important to determine that the system would run as expected. The Organisation, IPT and 6D jointly conducted pre-launch testing. The Organisation as the end user, and IPT as the Organisation’s data intermediary, should have scoped the pre-launch testing to include a simulation of expected scenarios. In particular, the scenario in which migration to the New Platform is staggered and a high volume of email addresses would have been assigned Batch IDs for the sending of emails to the right subscriber (“Migration Scenario”). 7. However, in the pre-launch testing, the Migration Scenario was not catered for. Only two test accounts were used to check that the New Platform could generate and email invoices to the right parties. This was insufficient to simulate expected usage. Consequently, the tests failed to surface this issue. 8. The proper scoping of pre-launching testing is important for the detection of functionality issues that may put personal data at risk. In failing to simulate the expected scenarios, in particular the Migration Scenario, the Organisation and IPT failed to meet the reasonable standard required to discharge the Protection Obligation. 9. Furthermore, the processes to ensure that the New Platform would issue unique Batch IDs were inadequate. A date/time stamp could have been included as part of each Batch ID to avoid duplication, which was implemented only after the Incident. 10. In deciding to find the Organisation and IPT respectively in breach of the Protection Obligation under the Personal Data Protection Act 2012 (the “PDPA”) and to issue a Warning to each party, the Deputy Commissioner for Personal Data Protection took into account the following: a. Although the Organisation neither owned nor operated the New Platform, it remained a data controller in control of its subscribers’ Personal Data. b. IPT was the Organisation’s data intermediary in developing the New Platform, which included migration of the personal data of subscribers. IPT relied on Openet as its subcontractor, and the Batch ID duplication occurred as a result of errors during the migration that was performed by 6D. Notwithstanding the representations made by IPT, it retained a key role, together with the Organisation, in scoping the pre-launch testing of the New Platform. c. The tests proved to be inadequate and a reasonable opportunity to prevent the Incident was missed. For this, both the Organisation and IPT bore responsibility. 11. No directions are required as the Organisation and IPT had taken remedial actions to address the gaps in security arrangements respectively. ",Warning,9289b77ccf9c91c7e895f86b99071f8723ce5faf,"[""tags"",""decision"",""pdf-url"",""description"",""date"",""timestamp"",""url"",""title"",""nature"",""pdf-content""]" 2023-10-01T11:02:10+08:00,fbd32491db44d3d0c97aa12a99cefd61ec954264,97,97,1,1016,A warning was issued to Actstitude for failing to put in place reasonable security arrangements to prevent the unauthorised disclosure of individuals' personal data. Over 160 individuals uploaded their resumes to Actstitude's website and their personal data were accessible over the Internet.,"[""Protection"", ""Warning"", ""Information and Communications"", ""URL manipulation"", ""Vulnerability"", ""Access control"", ""Security""]",2020-08-03,https://www.pdpc.gov.sg/-/media/Files/PDPC/PDF-Files/Commissions-Decisions/Decision---Actstitude-Pte-Ltd---20032020.pdf,Protection,Breach of the Protection Obligation by Actstitude,https://www.pdpc.gov.sg/all-commissions-decisions/2020/08/breach-of-the-protection-obligation-by-actstitude,2020-08-03,"PERSONAL DATA PROTECTION COMMISSION Case No. DP-1910-B5129 In the matter of an investigation under section 50(1) of the Personal Data Protection Act 2012 And Actstitude Pte Ltd SUMMARY OF THE DECISION 1. Actstitude Pte Ltd (the “Organisation”) is a social media platform marketing agency. It has a webpage allowing individuals interested in joining the Organisation to upload their resumes. For each resume uploaded, a file was created with a Uniform Resource Locator (“URL”) and stored in a database. Between August 2018 to October 2019, over 160 individuals uploaded their resumes. 2. The Organisation, however, admitted that it did not put in place controls to restrict access to the resume files. The URLs generated by the Organisation could also be manipulated to access resume files uploaded by different individuals. 3. When the webpage was created on 5 July 2018, the Organisation did not conduct vulnerability scanning as part of pre-launch testing; neither did the Organisation conduct periodic security reviews. Such scans offer a reasonable chance of detecting both the lack of access controls and the vulnerability of the URLs to manipulation. 4. The result of this failure to put in place access controls or to conduct security testing was that Google indexed and disclosed the URLs when a search was made of the names in the uploaded resumes. The URLs could then be manipulated to access the resumes of other individuals. This led to a complaint to the Personal Data Protection Commission on 25 October 2019. 5. The Deputy Commissioner for Personal Data Protection therefore found that the Organisation did not adopt reasonable steps to protect personal data in its possession or under its control against risk of unauthorised disclosure. The Organisation was in breach of the Protection Obligation under section 24 of the Personal Data Protection Act 2012. Upon consideration of the facts, a warning was issued to the Organisation. No directions are required as the Organisation had taken action to address the gaps in its security arrangements. ",Warning,f67b98aac5af051e0230fe4d74d422bae5c57230,"[""tags"",""decision"",""pdf-url"",""description"",""date"",""timestamp"",""url"",""title"",""nature"",""pdf-content""]" 2023-10-01T11:02:10+08:00,fbd32491db44d3d0c97aa12a99cefd61ec954264,98,98,1,1016,"A warning was issued to Jean Yip Salon for failing to put in place reasonable security arrangements to prevent the unauthorised disclosure of personal data of its employees. As a result, the personal data of 28 individuals were accessible over the Internet.","[""Protection"", ""Warning"", ""Wholesale and Retail Trade"", ""Password"", ""Public access""]",2020-08-03,https://www.pdpc.gov.sg/-/media/Files/PDPC/PDF-Files/Commissions-Decisions/Decision---Jean-Yip-Salon-Pte-Ltd--13032020.pdf,Protection,Breach of the Protection Obligation by Jean Yip Salon,https://www.pdpc.gov.sg/all-commissions-decisions/2020/08/breach-of-the-protection-obligation-by--jean-yip-salon,2020-08-03,"PERSONAL DATA PROTECTION COMMISSION Case No. DP-1907-B4281 In the matter of an investigation under section 50(1) of the Personal Data Protection Act 2012 And Jean Yip Salon Pte Ltd SUMMARY OF THE DECISION 1. The Personal Data Protection Commission (the “Commission”) received a complaint on 16 July 2019 about an employee system (the “System”) maintained by Jean Yip Salon Pte Ltd (the “Organisation”) that was publicly accessible via the internet. The personal data of 28 individuals disclosed via the System included their name, NRIC number, residence status, date of birth, nationality, gender, mobile number and job designation. 2. The Commission found that the Organisation did not adopt reasonable measures to protect personal data in its possession against risk of unauthorised access. First, the Organisation opened public access to a server without ascertaining what it hosted. As a result, while enabling public access to the Customer Online Appointment Booking System, it inadvertently also allowed access to the System (meant only for internal use), which was also hosted on the same server. Second, there were no processes in place to remove or deactivate unnecessary user accounts of the System. Finally, the Organisation did not enforce a password policy for the user accounts of the System. As such, the complainant was able to gain access to the System by simply using a wellknown and weak default username and password pair. 3. In the circumstances, the Deputy Commissioner for Personal Data Protection found the Organisation in breach of section 24 of the Personal Data Protection Act 2012 and issued a warning to the Organisation. No directions were required as the Organisation had implemented corrective measures that addressed the gaps in its security arrangements. ",Warning,ebdd2c957a9673f4bcab7ed28d18a885209a8e04,"[""tags"",""decision"",""pdf-url"",""description"",""date"",""timestamp"",""url"",""title"",""nature"",""pdf-content""]" 2023-10-01T11:02:10+08:00,fbd32491db44d3d0c97aa12a99cefd61ec954264,99,99,1,1016,A warning was issued to FWD Singapore for failing to put in place reasonable security arrangements to prevent the unauthorised disclosure of 71 individuals’ personal data contained in payment advice letters which were sent to incorrect recipients.,"[""Protection"", ""Warning"", ""Finance and Insurance"", ""Letters"", ""Logic error"", ""Code review""]",2020-08-03,https://www.pdpc.gov.sg/-/media/Files/PDPC/PDF-Files/Commissions-Decisions/FWD-Singapore-Pte-Ltd---Summary-of-Decision---13032020.pdf,Protection,Breach of the Protection Obligation by FWD Singapore,https://www.pdpc.gov.sg/all-commissions-decisions/2020/08/breach-of-the-protection-obligation-by-fwd-singapore,2020-08-03,"PERSONAL DATA PROTECTION COMMISSION Case No. DP-1907-B4352 In the matter of an investigation under section 50(1) of the Personal Data Protection Act 2012 And FWD Singapore Pte Ltd SUMMARY OF THE DECISION 1. The Personal Data Protection Commission (the “Commission”) was notified on 26 July 2019 by FWD Singapore Pte Ltd (the “Organisation”) of the unintended disclosure of 71 individuals’ (the “Affected Individuals”) personal data contained in 42 payment advice letters sent to incorrect recipients between 20 June 2019 and 17 July 2019 (the “Incident”). 2. The Incident arose from the Organisation’s attempt to fix a logic error in the system that it used to generate payment advice letters. The error was introduced when a fix for an earlier logic error was deployed. The Commission found that the second logic error could have been detected if manual code review and unit testing had been conducted to a reasonable standard. 3. The second logic error caused the extraction of incorrect mailing addresses for payment advice letters in some circumstances. This resulted in the Affected Individuals’ names and identification numbers in payment advice letters being sent to incorrect addresses. The Organisation should have taken care in conducting its manual code review and unit testing to avoid another logic error. In the circumstances, the Deputy Commissioner for Personal Data Protection found the Organisation in breach of its Protection Obligation under section 24 of the Personal Data Protection Act 2012 (the “PDPA”). 4. The Deputy Commissioner took into account the following factors in deciding to issue a warning to the Organisation: a. The Organisation had managed to retrieve letters containing the personal data of 67 out of the 71 Affected Individuals. b. The Organisation voluntarily notified the Commission of the Incident. c. The second logic error resulted in the extraction of incorrect mailing addresses only in limited circumstances. 5. No directions are required as the Organisation took steps to improve its development processes to prevent the recurrence of the Incident. ",Warning,bb248e5764c08e64f81212ce9f5a5c65012fd88c,"[""tags"",""decision"",""pdf-url"",""description"",""date"",""timestamp"",""url"",""title"",""nature"",""pdf-content""]" 2023-10-01T11:02:10+08:00,fbd32491db44d3d0c97aa12a99cefd61ec954264,100,100,1,1016,"A financial penalty of $32,000 was imposed on CDP for failing to put in place reasonable security arrangements to prevent the unauthorised disclosure of individuals’ personal data. Mail sent by CDP were addressed to incorrect recipients.","[""Protection"", ""Financial Penalty"", ""Finance and Insurance"", ""Mail"", ""Unintended recipient""]",2020-08-03,https://www.pdpc.gov.sg/-/media/Files/PDPC/PDF-Files/Commissions-Decisions/Decision---The-Central-Depository-(Pte)-Limited-30032020.pdf,Protection,Breach of the Protection Obligation by CDP,https://www.pdpc.gov.sg/all-commissions-decisions/2020/08/breach-of-the-protection-obligation-by-cdp,2020-08-03,"PERSONAL DATA PROTECTION COMMISSION [2020] SGPDPC 12 Case No DP-1905-B3847 In the matter of an investigation under section 50(1) of the Personal Data Protection Act 2012 And The Central Depository (Pte) Limited … Organisation DECISION 1 The Central Depository (Pte) Limited [2020] SGPDPC 12 Tan Kiat How, Commissioner — Case No DP-1905-B3847 30 March 2020 Introduction 1 The Central Depository (Pte) Limited (the “Organisation”) provides integrated clearing, settlement and depository facilities for its account holders (“CDP Account Holders”) in the Singapore securities market. On 3 May 2019, the Organisation notified the Personal Data Protection Commission (the “Commission”) that dividend cheques of some CDP Account Holders had been mailed to outdated addresses, resulting in the disclosure of their personal data to other individuals. Facts of the Case 2 Prior to 10 December 2018, the Organisation used a software known as the Post Trade System (“PTS”) for the purposes of post trade processing. The Organisation developed and customised additional modules that interfaced with PTS, including a module for the printing of dividend cheques (“Dividend Cheque Module”). The Dividend Cheque Module was used to automate the generation of dividend cheque mailers (i.e. mailers enclosing dividend cheques to be posted to CDP Account Holders). 3 Subsequently, the Organisation purchased another software, the New Post Trade System (“NPTS”) to replace the PTS. In comparison to the PTS, the NPTS facilitated record keeping that was more comprehensive. The PTS only recorded a CDP Account Holder’s latest address, while the NPTS kept records of the CDP Account Holder’s updated address as well as historical addresses.1 Arising from the new feature of the NPTS that kept records of CDP Account Holders’ updated addresses and historical addresses, the Organisation updated the programming logic of the Dividend Cheque Module (and all other modules that required retrieving of addresses) to extract the CDP Account Holders’ updated addresses. 1 As there was only one address for each CDP Account Holder stored in the PTS, a query for the address would always extract that address of the CDP Account Holder. 2 4 Prior to migration from PTS to NPTS, the Organisation conducted several tests, which included the following: (a) A test for the change of address for the module that generated notification letters acknowledging a change of address. This included checking that the notification letters extracted the updated address (the “Notification Letters Test”); (b) A test for the extraction of CDP Account Holders’ personal data for the Dividend Cheque Module. The scope of this test did not include the scenario of change of address (i.e. whether the Dividend Cheque Module would extract the updated address in the event a CDP Account Holder changed its address) (the “Dividend Cheque Module Test”); and (c) Manual code review of the additional modules (including the Dividend Cheque Module). 5 On 10 December 2018, the Organisation migrated from PTS to NPTS. As the tests mentioned at [4] did not detect any errors, the Organisation was unaware that the Dividend Cheque Module may not consistently extract a CDP Account Holder’s updated address. 6 On 20 March 2019, a CDP Account Holder complained that the Organisation had mailed a cheque for dividends to an outdated address (“First Incident”). The Organisation commenced investigations immediately. However, the Organisation’s technical team was unable to replicate the error and identify the issue that caused the First Incident. The results for the Dividend Cheque Module Test returned the correct addresses, including the complainant’s correct address. 7 Subsequently, on 12 April 2019, the Organisation’s customer service team received an email from the Monetary Authority of Singapore (“MAS”) in relation to a complaint (“Second Incident”). Meanwhile, notwithstanding that the Organisation’s technical team was unable to identify the issue that caused the First Incident, to further reinforce the programming logic, they introduced a defensive measure with a clause to consistently extract the updated addresses (the “Fix”). On 20 April 2019, the Organisation deployed the Fix into the production environment. 3 8 After several rounds of correspondence and additional information provided by MAS on 30 April 2019 in relation to the Second Incident, the Organisation realised that the issue pertaining to the First Incident and Second Incident may have a wider impact than originally anticipated. The Organisation conducted further investigations which revealed that all of the modules involving the retrieval of addresses were correctly coded except the Dividend Cheque Module. The error in the code in the Dividend Cheque Module (which resulted in the programme logic not consistently extracting a CDP Account Holder’s updated address) had caused the First Incident and Second Incident. Due to the implementation of the Fix as mentioned at [7], the error had been permanently resolved by this time. 9 According to the Organisation, 542 CDP Account Holders were due to receive dividend cheque mailers, and had previously updated their addresses. Out of the 542 CDP Account Holders whose personal data was at risk of unauthorised disclosure, the Organisation confirmed that 331 CDP Account Holders had presented their dividend cheques, indicating that their dividend cheque mailers had been sent to the correct addresses. By deduction, there were accordingly 211 CDP Account Holders (“Affected Individuals”) whose dividend cheque mailers were sent to outdated addresses. 10 The information disclosed in the dividend cheque mailers (collectively, “Disclosed Data”) were: 11 (a) Name of client; (b) NRIC number; (c) Central Depository (Pte) Limited (“CDP”) account number; (d) Name of security; (e) Quantity of security held; and (f) Dividend amount. During the course of its investigations into the First Incident and Second Incident, the Organisation took the following remedial actions: 4 (a) On 20 April 2019, introduced an additional measure to ensure that the updated address of CDP Account Holders would be extracted in the Dividend Cheque Printing Module; (b) Reviewed all modules which interfaced with NPTS and which involved the extraction of addresses to confirm that the error was specific only to the Dividend Cheque Module; and (c) Re-issued replacement cheques and explanation letters to the Affected Individuals. 12 In addition, the Organisation will also be conducting refresher training to ensure that its teams report issues under their respective purview as soon as practicable (even when similar type of issues had previously been raised), so that necessary follow up action may be taken. Findings and Basis for Determination Whether the Organisation had contravened section 24 of the PDPA 13 It is undisputed that the Disclosed Data constitutes “personal data” as defined in section 2(1) of the Personal Data Protection Act 2012 (“PDPA”), and the Organisation had possession and/or control over the Disclosed Data at all material times. 14 Section 24 of the PDPA requires an organisation to protect personal data in its possession or under its control by taking reasonable security steps or arrangements to prevent unauthorised access, collection, use, disclosure, copying, modification, disposal or similar risks. The fact that the Disclosed Data included NRIC numbers and personal data of a financial nature (i.e. CDP account number, name and quantity of security held, and dividend amount) is relevant in assessing the standard of reasonable security arrangements required. As emphasized in previous decisions, when it comes to the protection of personal data of a sensitive nature, stronger security measures must be put in place due to the actual or potential harm, and the severity of such harm, that may befall an individual from an unauthorised use of such data. 2 Having in mind the sensitivity of the Disclosed Data, the Organisation failed to put in place 2 See for example, Re Credit Counselling Singapore [2017] SGPDPC 18 at [25]; Re Aviva Ltd [2018] SGPDPC 4 at [17]; DS Human Resource Pte. Ltd. [2019] SGPDPC 16 at [9(c)]; and AIA Singapore Private Limited [2019] SGPDPC 20 at [12]. 5 reasonable security arrangements to protect the Disclosed Data for the reasons explained below. 15 When the Organisation migrated from PTS to NPTS, it had an obligation to conduct proper and adequate testing of the NPTS and its implementation that simulated real world usage of the system. This was critical in order to prevent errors from compromising the security of the Disclosed Data. In particular, and as mentioned at [3], the NPTS had a new feature which kept records of both the updated addresses of CDP Account Holders as well as their historical addresses, and the Organisation was relying on the NPTS and its customised additional modules to extract the correct address when generating the dividend cheque mailers. 16 The Commission’s investigations revealed that the Organisation failed to conduct sufficient testing before migrating from PTS to NPTS for the following reasons: (a) First, the scope of the testing for the Dividend Cheque Module was too narrow and did not include the scenario of change of address. This omission was unacceptable given that (i) change of address was a known scenario (which was tested in the module with respect to generation of notification letters that acknowledged change of address); and (ii) the Organisation relied on the Dividend Cheque Module to extract the updated address and automate the generation of dividend cheque mailers; (b) Secondly, the Organisation should have tested the Dividend Cheque Module in an environment that simulated real world usage of the system. This required the Organisation to not only scope the tests to include the change of address scenario, but also to have a sufficient number of test cases to properly test these scenarios; and (c) Thirdly, the Organisation had conceded that there was a “reasonable chance” that the error in the Dividend Cheque Module may have been detected if the scope of the tests had included the change of address scenario with a sufficient number of tests cases. 17 For the reasons above, the Commissioner found the Organisation in breach of section 24 of the PDPA. 6 Representations by the Organisation 18 In the course of settling this decision, the Organisation made representations on the amount of financial penalty that was to be imposed. The Organisation raised the following factors for consideration: (a) The Organisation had expended its best efforts in testing: (i) Prior to migration from PTS to NPTS, the Organisation carried out the Notification Letter Test and the Dividend Cheque Module Test. Both tests did not return any errors. In view of this, the Organisation did not contemplate further targeted testing at the material time. (ii) Even if the Organisation had expanded the scope of the Dividend Cheque Module Test to cover the change of address scenario and increased the relevant test cases, such testing may have still failed to reveal the defect. In this regard, after being informed of the First Incident, the Organisation was unable to replicate the error through repeated testing with real world cases. (b) There was no risk of actual financial loss. (i) The dividend cheques were made out to the names of the Affected Individuals and could only be encashed into accounts bearing such names. (ii) The Disclosed Data of each Affected Individual was disclosed only to a single recipient, as opposed to the world at large. The Disclosed Data was also insufficient, in and of itself, to be used by a recipient to impersonate or execute any transaction in the name of an Affected Individual. (iii) The Organisation used a specific envelope for the mailing of dividend cheques to minimise unauthorised access to the Disclosed Data, save in wilful circumstances. Each envelope was marked “Private & Confidential” and “To be opened by addressee only”. A return address was printed on the face of the envelope, to cater for the event that the letter was not properly delivered to the addressee. 7 (c) Upon establishing the number of dividend cheques affected on 3 May 2019, the Organisation promptly notified the Affected Individuals and the Commission. The Organisation also took proactive and prompt remedial steps at [11]. (d) The financial penalty imposed should be consistent with the Commission’s previous decisions and commensurate with the scale of the Incident. Taking into consideration the number of Affected Individuals in the present case and financial penalties imposed in the Commission’s previous decisions involving similar number of affected individuals, a warning would suffice. In the alternative, the Organisation submitted that any financial penalty imposed should not exceed $5,000. 19 Having carefully considered the representations, the Commissioner has decided to maintain the financial penalty set out at [21] for the following reasons: (a) As explained in [15] to [16], the Organisation failed to conduct sufficient testing before migrating from PTS to NPTS. The module that generated notification letters acknowledging a change of address was coded independently from the Dividend Cheque Module. The Organisation should not have relied on test results from the Notification Letters Test as assurance that there were no errors in the Dividend Cheque Module, and it would consistently extract a CDP Account Holder’s updated address. (b) The Organisation’s representations that there was no risk of financial loss cannot be accepted. Although the risk of financial loss was reduced because the dividend cheques were made out to the names of the Affected Individuals, there was still a risk of fraud i.e. the unauthorised individuals who received the dividend cheque mailers could have fraudulently altered the names on the dividend cheques and presented them for encashment. In addition, for the period between the Incident and the Organisation issuing the replacement cheques, the Affected Individuals would have been deprived of the use of funds they would have otherwise access to. As for the Organisation’s representations on the specific envelopes used for the mailing of dividend cheques, the fact that the dividend cheques mailers were sent to unauthorised individuals meant that there was a risk of further unauthorised access, use and disclosure of the Disclosed Data. 8 (c) The Organisation’s voluntary notification of the Incident to Affected Individuals and the Commission, as well as the Organisation’s proactive and prompt remedial steps had already been taken into consideration in determining the financial penalty at [21]. (d) With respect to the Organisation’s representations comparing the present case to earlier decisions, it needs only to be said that each decision is based on the unique facts of each case. The decision in each case takes into consideration the specific facts of the case so as to ensure that the decision and direction(s) are fair and appropriate for that particular organisation. The Commissioner’s Directions 20 In the assessment of the breach and determination of the directions, if any, to be imposed on the Organisation under section 29 of the PDPA, the fact that the Affected Individuals were put at risk of actual financial loss was an aggravating factor. The dividend cheques mailers were sent to outdated addresses and there was a risk that they may have been banked in by unauthorised persons. The Affected Individuals would also have been deprived of the use of the funds they would have otherwise access to, had they received and banked in the dividend cheques. On the other hand, the following mitigating factors were also considered: (a) the Organisation took prompt remedial actions to rectify the error and mitigate the effects of the breach; and (b) 21 the Organisation was cooperative with the Commission’s investigations. In consideration of the relevant facts and circumstances, the Commissioner hereby directs the Organisation to pay a financial penalty of $32,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. The Commissioner has not set out any further directions given the remediation measures already put in place. YEONG ZEE KIN DEPUTY COMMISSIONER FOR COMMISSIONER FOR PERSONAL DATA PROTECTION 9 ",Financial Penalty,c533793aa9a8e3bfcebfd59e65b4ee2051754090,"[""tags"",""decision"",""pdf-url"",""description"",""date"",""timestamp"",""url"",""title"",""nature"",""pdf-content""]"