_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,151,151,1,952,"A financial penalty of $10,000 was imposed on AIA for failure to take reasonable security arrangements in its letter generation process.","[""Protection"", ""Financial Penalty"", ""Finance and Insurance"", ""Insurance""]",2019-06-20,https://www.pdpc.gov.sg/-/media/Files/PDPC/PDF-Files/Commissions-Decisions/Grounds-of-Decision---AIA-Singapore-Pte-Ltd---200619.pdf,Protection,Breach of the Protection Obligation by AIA,https://www.pdpc.gov.sg/all-commissions-decisions/2019/06/breach-of-the-protection-obligation-by-aia,2019-06-20,"PERSONAL DATA PROTECTION COMMISSION [2019] SGPDPC 20 Case No DP-1801-B1530 In the matter of an investigation under section 50(1) of the Personal Data Protection Act 2012 And AIA Singapore Private Limited … Organisation DECISION AIA Singapore Private Limited [2019] SGPDPC 20 Tan Kiat How, Commissioner — Case No DP-1801-B1530 20 June 2019 Background 1 On 5 January 2018, the Organisation notified the Personal Data Protection Commission (the “Commission”) of the potential unauthorised disclosure (the “Incident”) of individuals’ personal data contained in 244 letters sent to two individuals due to an error with its letter generation system. In particular, 245 letters meant for various customers that the Organisation generated on 22 December 2017 and 27 December 2017 were sent to two customers as follows: (a) 179 letters were sent to the first customer (“Customer X”), of which 178 letters were received by him (with one having gone missing in transit); and (b) 66 letters were sent to, and received by, the second customer (“Customer Y”). Customer Y was the intended recipient of only one of these letters. 2 Following an investigation into the matter by the Commission, the Commissioner found the Organisation in breach of section 24 of Personal Data Protection Act 2012 (“PDPA”) for the reasons set out below. AIA Singapore Private Limited [2019] SGPDPC 20 Material Facts 3 The Incident arose from an error in the Organisation’s “Integral Life System” (the “System”) which was used to automatically generate certain types of letters to its customers. The error was introduced into the System as a result of the Organisation deploying a software fix (the “Fix”) on 21 December 2017 to rectify an earlier error (the “First System Error”). The First System Error resulted in the Organisation sending duplicate letters to customers who had provided the Organisation with only a foreign despatch address (ie they had not provided any local despatch address in Singapore). 4 Unfortunately, the Fix inadvertently introduced a logic error1 which caused the System to extract and reflect the wrong local despatch addresses on the affected letters. This logic error manifested itself when the System generated “HealthShield Non-Integrated for Foreigners Policy” letters (“Type A letter”) and letters which were not Type A letters (“non-Type A letter”) in a batch; the local despatch address of the non-Type A letters generated immediately after a Type A letter incorrectly reflected the local despatch address of that Type A letter (the “Error”). A more detailed description of this Error is provided below: (a) When the System generates Type A letters (ie Letters 1 and 2 in Table 1 below), the Type A letters accurately reflect the local and/or foreign despatch address of the intended recipients. (b) If the System then generates non-Type A letters (ie Letters 3, 4 and 5 in Table 1) immediately after a Type A letter, the non- 1 A logic error is a glitch in a computer programme that causes it to operate incorrectly and produce unintended output or other behaviour, but not to crash. 3 AIA Singapore Private Limited [2019] SGPDPC 20 Type A letters wrongly reflect the local despatch address of the recipient of the last Type A letter (ie Letter 2 in Table 1), but accurately reflect their foreign despatch address (if any) (eg Letters 4 and 5 in Table 1). (c) If the System generates Type A letters after a non-Type A letter (ie Letter 6 in Table 1), the Type A letters accurately reflect the local and/or foreign despatch address of the intended recipients. 5 Table 1 below illustrates the effects of the Error: Table 1: Illustration of Error Letter Letter System Number, Type Record in sequential Local order Address 1 Type Tampines A 2 Type Ang Mo A Kio 3 NonBedok Type A 4 NonUbi Type A 5 NonType A 6 Type Eunos A 7 Type East A Coast 8 Type A Policy Despatch Address Outcome generated in the letters Foreign Local Foreign Address Address Address Tampines India - USA Ang Mo Kio Ang Mo Kio Ang Mo Kio Australia Ang Mo Kio - Eunos France East Coast - Vietnam 4 India - Letters 3 to 5 were sent to the local USA despatch address Australia reflected in Letter 2 above. France Vietnam AIA Singapore Private Limited 6 [2019] SGPDPC 20 In this case, the letters generated were therefore all addressed to their intended recipients but 179 letters reflected the local despatch address of Customer X and 66 letters reflected the local despatch address of Customer Y. This is because Customers X and Y were in the position of the recipient of the last Type A letter (eg Letter 2 in Table 1) before the batch of non-Type A letters were generated. 7 After the 245 letters were generated, they were converted into PDF format and sent to the Organisation’s vendor, DataPost Pte Ltd (“DataPost”), for printing, enveloping and despatch. These letters comprised four Integrated Shield Plan premium notice reminder letters, 237 Integrated Shield Plan premium notice letters, three change of payor letters and one modified terms of coverage letter. These letters were sent to Customers X and Y between 28 December 2017 and 2 January 2018. 8 As a result of the Error, the following types of personal data for each category of letters were potentially compromised: (a) in respect of the modified terms of coverage letters, and Integrated Shield Plan premium notice letters and premium notice reminder letters: (i) the policyholder or insured person’s full name; (ii) the policyholder or insured person’s policy number; (iii) the policyholder or insured person’s type and name of policy; (iv) the policyholder or insured person’s policy premium due date; and 5 AIA Singapore Private Limited (v) (b) [2019] SGPDPC 20 the policyholder or insured person’s premium amount. in respect of the change of payor letters: (i) the intended recipient’s full name; (ii) the intended recipient’s policy number; (iii) the intended recipient’s type and name of policy; (iv) the intended recipient’s policy anniversary date; (v) the insured person’s full name, which differs from the intended recipient as the latter was paying the premiums on behalf of the insured; and (vi) 9 the intended recipient’s premium amount. On 30 December 2017, the Organisation learnt about the Incident from a social media post by Customer X and discovered the Error. It took the following remedial actions to mitigate the damage caused and to prevent the recurrence of similar incidents: (a) immediately implemented a software fix to resolve the Error in the System; (b) conducted and completed a scan of the System to check that all Singapore despatch addresses for letters sent to the Organisation’s customers in 2017 were accurate; (c) implemented a function in the System to enable it to perform, and generate daily reports for the purposes of, the following: 6 AIA Singapore Private Limited (i) [2019] SGPDPC 20 checking and validating that the despatch addresses printed on the automatically generated letters match the records of the intended recipients, as found in the System’s database; and (ii) flagging out non-conforming cases to automatically stop such letters from being transmitted to DataPost for printing; (d) took steps to retrieve the 244 letters which were sent to the wrong addresses and successfully retrieved 243 unopened letters. One letter was never received by Customer X and was determined to have been lost in transit; and (e) printed and re-sent the affected letters to the customers concerned and extended their deadline to respond to the matters contained therein. Findings and Basis for Determination 10 The main issue for determination is whether the Organisation breached section 24 of the PDPA. 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. 11 As a preliminary point, the Organisation had engaged DataPost to assist with the printing, enveloping and despatch of the letters on the Organisation’s behalf. According to the agreement between the Organisation and DataPost, and 7 AIA Singapore Private Limited [2019] SGPDPC 20 as admitted by the Organisation in its responses to the Commission’s queries, the scope of DataPost’s engagement did not include checking the substantive contents of the letters it printed, enveloped and despatched on behalf of the Organisation; DataPost was only required to conduct sampling checks of the printouts in relation to the quality of presentation and alignment. Accordingly, the Incident did not relate to the scope of DataPost’s engagement under its agreement with the Organisation. 12 Before examining the arrangements put in place by the Organisation, it should be noted that the personal data involved in this case includes insurance data, a category of personal data that is considered to be of a sensitive nature. It has been stated in previous decisions2 that personal data of a sensitive nature should be safeguarded by a higher level of protection. To reiterate Re Aviva Ltd [2018] SGPDPC 4 at [17]: “All forms or categories of personal data are not equal; organisations need to take into account the sensitivity of the personal data that they handle. In this regard, the Commissioner repeats the explanation in Re Aviva Ltd [2017] (at [18]) on the higher standards of protection that should be implemented for sensitive personal data: The Advisory Guidelines on Key Concepts in the PDPA states that an organisation should “implement robust policies and procedures for ensuring appropriate levels of security for personal data of varying levels of sensitivity”. This means that a higher standard of protection is required for more sensitive personal data. More sensitive personal data, such as 2 See, for example, Re AIG Asia Pacific Insurance Pte Ltd & Toppan Forms (S) Pte Ltd [2019] SGPDPC 2, Re NTUC Income Insurance Co-operative Ltd [2018] SGPDPC 10, Re AIG Asia Pacific Insurance Pte Ltd [2018] SGPDPC 8, Re Aviva Ltd [2018] SGPDPC 4, and Re Aviva Ltd [2017] SGPDPC 14. 8 AIA Singapore Private Limited [2019] SGPDPC 20 insurance, medical and financial data, should be accorded a commensurate level of protection. In addition, the Guide to Preventing Accidental Disclosure When Processing and Sending Personal Data expressly states that documents that contain sensitive personal data should be “processed and sent with particular care”.” [Emphasis added.] 13 In this case, in order to determine whether the Organisation was in breach of section 24, the relevant question is whether it had put in place reasonable security arrangements that would have prevented the Incident. It appears from the Commission’s investigations that the Organisation had failed to: (a) conduct sufficient testing before rolling out the Fix for the First System Error; and (b) institute sufficient controls or checks to ensure the accuracy of the letters that the System automatically generated. 14 With respect to the failure set out above at paragraph 13(a), the tests which the Organisation conducted after developing the Fix were limited to ensuring that the First System Error was addressed (ie that duplicate letters were not sent to customers who had provided the Organisation with only a foreign despatch address). The scope of these tests was too narrow. Since changes were made to address how the System handled retrieval and insertion of local and foreign addresses, these tests should have been designed to ensure that the Fix did not affect other aspects of the System involving the same functionality. 9 AIA Singapore Private Limited 15 [2019] SGPDPC 20 Additionally, the tests were not conducted to mimic real world usage of the System. Firstly, the Organisation conducted its tests by generating one letter at a time. However, the System was ordinarily required to generate letters in batches which included both Type A and non-Type A letters, and the Error in fact only arose when the letters were generated in such batches. If the Organisation had tested the batch processing functionality using test data that approximated real world scenarios, the Error would have likely come to light at that stage. 16 Secondly, the Organisation used a set of test data that was severely flawed. The test data used a single address, 1 Robinson Road, as the local despatch address for all the letters that were generated. The Organisation claimed to have done this in order to prevent the disclosure of production data. There are proven ways to generate dummy or test data that reflects the distribution of the production data without resorting to using a single address, eg by swapping3 the data. Further, this measure would also have prevented them from detecting the Error even if they had tested the generation of letters in batches. 17 With respect to the failure set out above at paragraph 13(b), the Organisation admitted that it did not have in place any process or personnel responsible for checking the contents of the automatically generated letters. The Guide to Preventing Accidental Disclosure When Processing and Sending Personal Data states the following in relation to the use of automated processes: “Ensure the accuracy and reliability of the automated processing 3 The purpose of swapping is to rearrange data in the dataset such that the individual attribute values are still represented in the dataset, but generally, do not correspond to the original records. This technique is also referred to as shuffling and permutation. For more details, please refer to the Commission’s Guide to Basic Data Anonymisation Techniques. 10 AIA Singapore Private Limited [2019] SGPDPC 20 implemented by checking these systems and processes regularly. When the data is more sensitive, consider incorporating additional checking mechanisms to cater for unexpected situations and ensure no error arises from the automated processing. As good practice, establish procedures to include additional checks following the processing, printing and sorting of documents to ensure that the destination information (e.g. mailing address, email address or fax number) is correct and matches that of the intended recipient(s) prior to sending.” [Emphasis added.] 18 Given the sensitive nature of the personal data involved, the Organisation ought to have instituted controls or checks to ensure the accuracy of the addressees of the letters. This is something that the Organisation has since implemented. 19 For the reasons above, the Commissioner found the Organisation in breach of section 24 of the PDPA. The Commissioner’s Directions 20 Having found that the Organisation is in breach of section 24 of the PDPA, the Commissioner is empowered under section 29 of the PDPA to issue the Organisation such directions as he deems fit to ensure compliance with the PDPA. 21 In assessing the breach and determining the directions, if any, to be imposed on the Organisation in this case, the following mitigating factors were taken into consideration: 11 AIA Singapore Private Limited (a) [2019] SGPDPC 20 the Organisation voluntarily notified the Commission of the breach; (b) the Organisation fully cooperated with the Commission’s investigations; (c) the Organisation took prompt action to mitigate the effects of the breach; and (d) 22 the Organisation managed to retrieve 243 letters unopened. In consideration of the relevant facts and circumstances of the present case, the Commissioner directs the Organisation to pay a financial penalty of $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 such financial penalty until the financial penalty is paid in full. 23 The Commissioner has not made any further directions for the Organisation given the remediation measures already put in place. YEONG ZEE KIN DEPUTY COMMISSIONER FOR COMMISSIONER FOR PERSONAL DATA PROTECTION 12 ",Financial Penalty,d16b9d4902b7da4ff4474bdf5eb9393d29ad7f07,"[""pdf-content"",""timestamp"",""decision"",""pdf-url"",""tags"",""nature"",""url"",""title"",""date"",""description""]" 2023-10-01T11:02:10+08:00,fbd32491db44d3d0c97aa12a99cefd61ec954264,152,152,1,952,A warning was issued to Xbot for failing to put in place data protection policies to comply with the provisions of the PDPA.,"[""Accountability"", ""Warning"", ""Real Estate"", ""Property""]",2019-06-20,https://www.pdpc.gov.sg/-/media/Files/PDPC/PDF-Files/Commissions-Decisions/Grounds-of-Decision--Xbot-Pte-Ltd---200619.pdf,Accountability,Breach of the Openness Obligation by Xbot,https://www.pdpc.gov.sg/all-commissions-decisions/2019/06/breach-of-the-openness-obligation-by-xbot,2019-06-20,"PERSONAL DATA PROTECTION COMMISSION [2019] SGPDPC 19 Case No DP-1803-1781 In the matter of an investigation under section 50(1) of the Personal Data Protection Act 2012 And Xbot Pte. Ltd. … Organisation DECISION Xbot Pte. Ltd. [2019] SGPDPC 19 Yeong Zee Kin, Deputy Commissioner — Case No DP-1803-1781 20 June 2019 Introduction 1. On 2 March 2018, the Personal Data Protection Commission (the “Commission”) received a complaint that Xbot Pte. Ltd. (the “Organisation”) had disclosed the personal data of property owners through the Strata.sg mobile application without their consent. The Commission commenced an investigation in order to determine whether the Organisation had failed to comply with its obligations under the Personal Data Protection Act 2012 (the “PDPA”). Material Facts 2. The Organisation developed and operated the Strata.sg mobile application (the “App”) and an associated website, http://Strata.sg (the “Website”), which provided access to a database of residential property transactions (the “Database”). The Database included information on transactions involving both private residential properties (“Private Properties”) and Housing Development Board (“HDB”) properties (“HDB Properties”). This information was made available to users of the App and Website and included a partial address (block number, road and, for HDB Properties only, a storey range), area, type and price for the properties listed. In addition, the complete addresses of the Private Properties (including the specific unit number) was made available to premium subscribers of the App or Website who paid a fee for access to the information in the Database. 3. The Organisation also collected personal data from users of the Website and users of the App in order to grant them access to the Database. The Organisation had a data protection policy for the Website (which it referred to as a “Privacy Policy”) but that policy did not 1 Xbot Pte. Ltd. [2019] SGPDPC 19 mention or cover the personal data collected from users of the App. The App did not include any separate data protection policy nor any link to the Organisation’s data protection policy for the Website. In addition, the Organisation did not have any internal policies or procedures relating to its personal data practices. At the material time, the Organisation was run by a single individual who was also an employee of the Organisation. The Organisation had only one other employee. Findings and Basis for Determination (A) Does the information in the Database constitute personal data under the PDPA? 4. 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.” 5. The information in the Database would not, on its own, be personal data as none of those data could identify an individual (per limb (a) of the above definition). In particular, as there is no publicly available means of identifying the owners of the HDB Properties based on the information available in the Database, the information relating to HDB Properties would not constitute personal data under the PDPA. 6. However, the complete addresses of the Private Properties in the Database could be used to trace the name of the owners of those properties through the Singapore Land Authority’s Land Titles Register. The information in the Database could then be related to the identified or identifiable owners of the Private Properties and reveal the type and size of property they own and the price they paid for the property. In light of this, the information in the Database relating to Private Properties constitute personal data under the PDPA (per limb (b) of the above definition). 2 Xbot Pte. Ltd. (B) [2019] SGPDPC 19 Is the Organisation permitted to collect, use and disclose the personal data in the Database? 7. Section 13 of the PDPA prohibits organisations from collecting, using or disclosing personal data about an individual for a purpose unless: (a) the individual consents, or is deemed to have consented, under the PDPA to such collection, use or disclosure; or (b) collection, use or disclosure without the individual’s consent is permitted or required under the PDPA or any other written law. 8. In the course of the Commission’s investigation, the Organisation admitted that it had not obtained the consent of the individuals concerned for the collection, use and disclosure of their personal data in the Database. Hence, the key issue is whether the Organisation is permitted to do so without the individuals’ consent. 9. Under section 17(1) of the PDPA, collection of personal data without consent is permitted in the circumstances listed in the Second Schedule to the PDPA. In particular, paragraph 1(c) of the Second Schedule permits the collection of personal data without consent if the personal data is publicly available. Section 2(1) of the PDPA defines the term “publicly available” (in relation to personal data) as “personal data that is generally available to the public …”. Use and disclosure of personal data which is publicly available is similarly permitted without consent under section 17(2) read with paragraph 1(c) of the Third Schedule and section 17(3) read with paragraph 1(d) of the Fourth Schedule respectively. 10. In this case, the information in the Database had either been obtained by the Organisation from a source which was generally available to the public or had been derived by the Organisation from information which had obtained from such a source. In particular, the Organisation had obtained information from the Urban Redevelopment Authority’s Real Estate Information System (“REALIS”) portal and the HDB’s Resale Flat Prices portal. The information in these portals are available to members of the public (in some cases, upon payment of a fee). In my view, such information is generally available to the public. 3 Xbot Pte. Ltd. 11. [2019] SGPDPC 19 In the circumstances, I find that the Organisation is permitted under the PDPA to collect, use and disclose the personal data in the Database without consent of the relevant individuals. The Organisation is therefore not in breach of section 13 of the PDPA. (C) Did the Organisation have in place the necessary data protection policies and practices under the PDPA? 12. Section 12 of the PDPA requires organisations to: (a) develop and implement policies and practices that are necessary for the organisation to meet the obligations of the organisation under the PDPA; (b) develop a process to receive and respond to complaints that may arise with respect to the application of the PDPA; (c) communicate to its staff information about the organisation’s policies and practices referred to in paragraph (a); and (d) 13. made information available on request about — (i) the policies and practices referred to in paragraph (a); and (ii) the complaint process referred to in paragraph (b). In this case, although the Website and the App collected the same personal data for the same purpose, the data protection policy published on the Website was expressly limited to personal data collected via the Website. This, in my view, is insufficient to meet the requirements of section 12 as users of the App would not have a clear indication of how their personal data would be handled by the Organisation. The Organisation should have ensured that its published data protection policy covered personal data regardless of whether it was collected via the Website or the App. This could have been done this with some simple amendments to the current data protection policy and, as a good practice, the App could have included a link to the policy published on the Website. Alternatively, the Organisation could include a separate data protection policy within the App. 14. In addition to an organisation’s published data protection policy, the “policies and practices” referred to in section 12 of the PDPA includes internal policies and processes that are necessary for the organisation to meet its obligations under the PDPA. While an organisation’s published data protection policy is meant to inform individuals about how their 4 Xbot Pte. Ltd. [2019] SGPDPC 19 personal data will be handled by the organisation, the internal policies and practices are meant for the organisation’s employees. Section 12 also requires such policies and practices to be communicated to the organisation’s staff. These requirements are intended to ensure that all employees of the organisation are aware of the specific practices they must adhere to when handing personal data including, for example, the notifications to be given to individuals when their personal data is collected, how access and correction requests should be handled, how personal data must be kept and secured and how personal data must be disposed of when no longer required by the Organisation. The specific internal policies and practices which may be required for a particular organisation would depend on various factors such as the following (among other factors): (a) the type(s) and amount of personal data collected by the organisation; (b) the organisation’s processes for collecting the personal data; (c) the organisation’s purposes for using or disclosing the personal data; and (d) the number and roles of employees who require access to personal data in the course of their employment. 15. In the present case, the Organisation has one employee (in addition to the sole director). Nevertheless, it should have developed internal policies and practices, having in mind the considerations enumerated in the preceding paragraph, and communicated them to its employee so as to ensure that its employee adhered to the appropriate practices when handling personal data (and related matters) in the course of his or her employment. Although the Organisation is a small company, size of the organisation is but one determinant of the complexity of the internal policies and practices required. The types and amount of personal data that it possesses and controls is another relevant consideration. In this regard, the Organisation possess and controls a not insignificant amount of personal data which relate to property ownership (even if these are publicly available). 16. In view of the above, I find the Organisation in breach of section 12 of the PDPA. 5 Xbot Pte. Ltd. [2019] SGPDPC 19 Conclusion 17. Having found the Organisation in breach of section 12 of the PDPA, I am empowered under section 29 of the PDPA to give to the Organisation such directions as I deem fit to ensure its compliance with the PDPA. 18. Taking the totality of the circumstances into account, I have decided to issue a warning to the Organisation for its breach of section 12 of the PDPA without further directions or imposing a financial penalty. In particular, I noted that- a) the Organisation had ceased operations of both the App and the Website on 16 May 2018; and b) the Organisation has been cooperative throughout the investigations. YEONG ZEE KIN DEPUTY COMMISSIONER FOR PERSONAL DATA PROTECTION 6 ",Warning,d2e2fb18265e0bede337a2a87e9f9ab6c61a81af,"[""pdf-content"",""timestamp"",""decision"",""pdf-url"",""tags"",""nature"",""url"",""title"",""date"",""description""]" 2023-10-01T11:02:10+08:00,fbd32491db44d3d0c97aa12a99cefd61ec954264,153,153,1,952,Cigna Europe Insurance Company S.A.-N.V. was found not to be in breach of the PDPA in relation to allegation that it had failed to make reasonable security arrangements to prevent the unauthorised disclosure of the personal data of its policy members.,"[""Protection"", ""Not in Breach"", ""Finance and Insurance""]",2019-06-20,https://www.pdpc.gov.sg/-/media/Files/PDPC/PDF-Files/Commissions-Decisions/Grounds-of-Decision---Cigna-Singapore---200619.pdf,Protection,No Breach of Protection Obligation by Cigna Europe Insurance Company S.A.-N.V.,https://www.pdpc.gov.sg/all-commissions-decisions/2019/06/no-breach-of-protection-obligation-by-cigna-europe-insurance-company-s-a--n-v,2019-06-20,"PERSONAL DATA PROTECTION COMMISSION [2019] SGPDPC 18 Case No DP-1806-B2241 In the matter of an investigation under section 50(1) of the Personal Data Protection Act 2012 And Cigna Europe Insurance Company S.A.-N.V. … Organisation DECISION Cigna Europe Insurance Company S.A.-N.V. [2019] SGPDPC 18 Yeong Zee Kin, Deputy Commissioner — Case No DP-1806-B2241 20 June 2019 Background 1. Cigna Europe Insurance Company S.A.-N.V. is a company established in Belgium which offers health insurance solutions and coverage in Singapore through a registered branch office (the “Organisation”). On 1 June 2018, the Organisation notified the Personal Data Protection Commission (the “Commission”) of a data breach incident involving the inadvertent disclosure of certain personal data of individuals who had taken up health insurance coverage with the Organisation. The Commission commenced an investigation in order to determine whether the Organisation had failed to comply with its obligations under the Personal Data Protection Act 2012 (the “PDPA”). Material Facts 2. The Organisation provides health insurance coverage to employees of its clients and their families who decided to take up such coverage (“Members”). In order to provide this health insurance coverage, it collects, uses and processes personal data of the Members. 3. In 2012, the Organisation entered into a services agreement (the “Services Agreement”) with Cigna European Services (UK) Limited (“CES”) for the provision of various insurance-related services. CES is a related company of the Organisation within the Cigna group of companies (“Cigna Group”). The services provided by CES included the processing of insurance claims (among other services) and this involved activities such as generating and sending claim settlement letters and letters accompanying cheque payments to 1 Cigna Europe Insurance Company S.A.-N.V. [2019] SGPDPC 18 Members who had made an insurance claim. Such claims were processed through an information technology (“IT”) system which was operated by CES and used by various companies in the Cigna Group (the “System”). In order to make use of the System, the Organisation transferred its Members’ personal data to CES and these data were processed in the System. 4. It transpired that, in two separate incidents in January 2017 and May 2018, claims settlement letters intended for certain Members were erroneously sent by CES to other Members. These incidents were due to technical issues affecting the production of the claims settlement letters by CES. In the second incident, the technical issues also affected the production of payment accompanying letters which were sent to some Members. CES initially did not inform the Organisation about the first incident. The Organisation only came to know about the two incidents after the second incident occurred. Findings and Basis for Determination 5. The cause of the data breach incidents in this case may be traced to the technical issues in the System. As these matters were not within the Organisation’s operational control or even its knowledge prior to May 2018, the Organisation does not bear any direct responsibility under the PDPA for the occurrence of the two incidents. 6. Nevertheless, as the processing of the Members’ personal data by CES was pursuant to the Services Agreement between the Organisation and CES, the question arises as to whether the Organisation had in place the appropriate measures to ensure protection of the Members’ personal data while the data was stored with and processed by CES. In this regard, section 24 of the PDPA requires organisations to protect personal data in their possession or under their control by making reasonable security arrangements to prevent unauthorised access, disclosure and similar risks. 7. I find that the Organisation had in place the appropriate measures or could rely upon measures established within the Cigna Group to ensure protection of personal data by CES and to monitor CES’ compliance. These measures include the following: 1 Cigna Europe Insurance Company S.A.-N.V. (a) [2019] SGPDPC 18 The Organisation and CES had entered into the Services Agreement and an Interaffiliate Data Processing and Transfer Agreement in 2012 which required CES to protect personal data transferred to it by the Organisation. For example, various clauses in these agreements required CES: (i) to protect the confidentiality of the Organisation’s customer data; (ii) to take appropriate and commercially reasonable measures to prevent, inter alia, unauthorised access or disclosure of such personal data and to ensure a level of security commensurate with the risks posed by the processing of personal data, (iii) to comply with a specified set of security safeguards; (iv) to notify the Organisation of any events that might impact the quality of CES’ services and products; (v) to give the Organisation access to the services for the purpose of reviewing and monitoring the quality of the services and the management of risks; and (vi) to give the Organisation’s internal and external auditors access to the services for the purpose of conducting audits; (b) There were various internal frameworks, policies and standards which apply to companies within the Cigna Group, including CES. These included, among others, the Cigna Information Protection (“CIP”) and General Computing Control (“GCC”) governance frameworks. These frameworks, policies and standards addressed various aspects of IT security (amongst other matters); and (c) CES was subject to Cigna Group’s corporate audit and annual GCC assessment processes which include security and data protection, as well as external audits which may include IT audit reviews. 8. Finally, as regards the causes of the two incidents, the Organisation has informed the Commission that the Cigna Group (including CES, the Organisation and other affected companies within the group) will be improving its processes in order to prevent a reoccurrence 2 Cigna Europe Insurance Company S.A.-N.V. [2019] SGPDPC 18 of the incidents. The actions of CES that were directly related to the two incidents took place outside our jurisdiction and were not part of the Commission’s present investigation. Application of section 26(1) of the PDPA to cross-border data transfers 9. As this case concerns personal data which had been transferred from the Organisation (in Singapore) to CES (in the United Kingdom), another question which may arise is whether the transfer meets the requirements of the PDPA. Section 26(1) of the PDPA prohibits organisations from transferring 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 relevant requirements are prescribed in Part III of the Personal Data Protection Regulations 2014 (the “PDPR”). In particular: (a) Regulation 9(1) of the PDPR requires an organisation (referred to in the PDPR as a “transferring organisation”), before transferring personal data from Singapore to a country or territory outside Singapore, to “take appropriate steps to ascertain whether, and to ensure that, the recipient of the personal data in that country or territory outside Singapore … 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 the protection under the [PDPA]”; (b) Regulation 10(1) provides that legally enforceable obligations (as referred to in regulation 9(1)) includes, among others, a contract in accordance with regulation 10(2); and (c) Regulation 10(2) provides that a contract referred to in regulation 10(1) must: (i) “require the recipient to provide a standard of protection for the personal data transferred to the recipient that is at least comparable to the protection under the [PDPA]”; and (ii) “specify the countries and territories to which the personal data may be transferred under the contract”. 3 Cigna Europe Insurance Company S.A.-N.V. 10. [2019] SGPDPC 18 The effect of the statutory provisions cited in the preceding paragraph is that when a transferring organisation in Singapore and an oversea recipient enter into a contract governing the transfer of personal data from the transferring organisation to the recipient, that contract must meet the two requirements specified in regulation 10(2) of the PDPR in order for the transferring organisation to have complied with section 26(1) of the PDPA. The second of these requirements (reproduced in paragraph 9(c)(ii) above) is self-explanatory. In relation to the first requirement (reproduced in paragraph 9(c)(i) above), the question is whether the contract requires the recipient to provide the appropriate standard of protection to the transferred personal data. 11. As stated in regulation 10(2) (and reproduced above), the standard of protection to the transferred personal data must be at least comparable to the protection under the PDPA. Determining the required standard for a particular contract would first involve considering how the PDPA applies to the personal data while it is in the possession or under the control of the transferring organisation (i.e. before the transfer to the recipient). The contract should then be drafted to impose comparable obligations on the recipient in respect of the PDPA’s nine main data protection obligations (as they are referred to in the Commission’s Advisory Guidelines on Key Concepts in the Personal Data Protection Act, in particular, at paragraph 10.2 thereof). These obligations are: (a) The Openness Obligation (sections 11 and 12 of the PDPA); (b) The Consent Obligation (sections 13 to 17 of the PDPA); (c) The Purpose Limitation Obligation (section 18 of the PDPA); (d) The Notification Obligation (section 19 of the PDPA); (e) The Access and Correction Obligations (sections 21 and 22 of the PDPA); (f) The Accuracy Obligation (section 23 of the PDPA); 4 Cigna Europe Insurance Company S.A.-N.V. 12. [2019] SGPDPC 18 (g) The Protection Obligation (section 24 of the PDPA); (h) The Retention Limitation Obligation (section 25 of the PDPA); and (i) The Transfer Limitation Obligation (section 26 of the PDPA). As a general point, it is not necessary that a contract addresses all nine obligations. This would depend on factors such as the purpose of the transfer, the nature of the relationship between the transferring organisation and the recipient and the scope of data processing services which the recipient may be providing to the transferring organisation. For example, if the recipient will not be assisting the transferring organisation with the handling of access and correction requests in relation to the transferred personal data, it would not be necessary for the contract to address the requirements of sections 21 and 22 of the PDPA. 13. In the present case, the Protection Obligation (section 24) is relevant to the transfer of personal data from the Organisation to CES. As discussed in the preceding section of this Decision, the Organisation had in place the appropriate security arrangements, including contractual provisions, which met the requirements of section 24 of the PDPA. Those contractual provisions would also meet the requirements of section 26(1) of the PDPA in relation to the Protection Obligation. (As an aside, this position would apply to other organisations in a similar relationship and similar circumstances, that is, where the recipient is a data intermediary of the transferring organisation and is processing personal data on behalf of and for the purposes of the transferring organisation.) 14. As the present case is concerned with the security arrangements put in place by the Organisation and the facts and circumstances of the case do not raise any particular concern as regards other aspects of the Organisation’s transfer of personal data to CES, the Commission did not investigate further into the Organisation’s compliance with section 26(1). I am satisfied that it is unnecessary to do so and hence make no finding in relation to that section. 5 Cigna Europe Insurance Company S.A.-N.V. [2019] SGPDPC 18 Conclusion 15. In light of the 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 6 ",Not in Breach,82befc3c459545f252183917e41a70959f2f78cd,"[""pdf-content"",""timestamp"",""decision"",""pdf-url"",""tags"",""nature"",""url"",""title"",""date"",""description""]" 2023-10-01T11:02:10+08:00,fbd32491db44d3d0c97aa12a99cefd61ec954264,154,154,1,952,"A financial penalty of $6,000 was imposed on InfoCorp for failing to put in place reasonable security arrangements to protect the personal data of individuals. Personal data of some individuals participating in a registration exercise via InfoCorp’s website were disclosed to other participants in the course of the registration exercise.","[""Protection"", ""Financial Penalty"", ""Finance and Insurance"", ""Crypto-currency""]",2019-06-20,https://www.pdpc.gov.sg/-/media/Files/PDPC/PDF-Files/Commissions-Decisions/Grounds-of-Decision---InfoCorp-Technologies-Pte-Ltd---200619.pdf,Protection,Breach of Protection Obligation by InfoCorp,https://www.pdpc.gov.sg/all-commissions-decisions/2019/06/breach-of-protection-obligation-by-infocorp,2019-06-20,"PERSONAL DATA PROTECTION COMMISSION [2019] SGPDPC 17 Case No DP-1802-B1674 In the matter of an investigation under section 50(1) of the Personal Data Protection Act 2012 And InfoCorp Technologies Pte. Ltd. … Organisation DECISION InfoCorp Technologies Pte. Ltd. [2019] SGPDPC 17 InfoCorp Technologies Pte. Ltd. Tan Kiat How, Commissioner — Case No DP-1802-B1674 20 June 2019 Background 1 The case concerns the unauthorised access and disclosure of personal data arising from a registration exercise for a crypto-currency initial coin offering (“ICO”). The Personal Data Protection Commission (“PDPC”) received six complaints on the matter on 5 February 2018. The Organisation also notified the PDPC of the matter on the same day. 2 Following an investigation into the matter, the Commissioner found the Organisation in breach of section 24 of Personal Data Protection Act 2012 (“PDPA”). The Commissioner’s findings and grounds of decision of the matter are set out below. Material Facts 3 The Organisation had conducted a crypto-currency ICO registration exercise via a website1 (“Website”) which it owned and managed at the material time. The registration exercise was scheduled to take place between 5 and 26 February 2018. 1 https://sentinel-chain.org/. InfoCorp Technologies Pte. Ltd. 4 [2019] SGPDPC 17 The registration process involved two main parts. (a) Individuals (“Participants”) were asked to input name, email address, date of birth, identification type and number, nationality, country of residence and residential address (“Personal Data Set”) on the registration page. (b) Participants also had to upload Know-Your-Customer (“KYC”) documents. A Uniform Resource Locator (“URL”) would be assigned to a Participant after he or she had uploaded the KYC documents and clicked “Save”. The KYC documents included the following: i. An identification document with a photograph of the Participant; ii. Documents showing proof of residence; and iii. A photograph of the Participant holding the identification document. 5 The incident was caused by a vulnerability in the design of the registration form. There was no requirement built into the system to authenticate the individuals downloading the KYC documents. The URL also contained a serialised file identity (“FileID”) as the last few characters of the URL in running numbers. The vulnerability allowed Participants assigned with a URL to access other Participants’ saved KYC documents by altering the last few characters of the assigned URL. The KYC documents of 21 Participants were downloaded by 15 other Participants via this vulnerability. 6 The Organisation took the server offline immediately after being informed by a Participant. The Organisation also contacted the 15 other 2 InfoCorp Technologies Pte. Ltd. [2019] SGPDPC 17 Participants who had downloaded the KYC documents. They were told to destroy the KYC documents not belonging to them. This includes any personal data of other Participants that they may have retained. 7 Prior to the incident, the Organisation had engaged a vendor to design the registration form for the Website. Data protection elements were considered by the Organisation. The Personal Data Sets were to be encrypted and rendered inaccessible to third parties. Nonetheless, the same level of diligence with respect to the uploaded KYC documents was not exercised by the Organisation. 8 The Organisation conducted standard functional tests on the Website’s process and user flow prior to launching it. However, these did not detect the vulnerability that caused the incident. The Organisation also did not conduct nor arrange for any penetration test or web application vulnerability scan. The Commissioner’s Findings and Basis for Determination 9 The issue for determination is whether the Organisation breached section 24 of the PDPA. 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. 10 The Organisation had full possession and control over the personal data collected from the Participants. Although the Organisation had engaged a vendor to design the registration form, the vendor did not process any personal data on behalf of the Organisation. The Organisation managed the Website on its own. Thus, it retained full responsibility for the IT security of the Website and the personal data contained therein. 3 InfoCorp Technologies Pte. Ltd. 11 [2019] SGPDPC 17 The Commissioner is satisfied that reasonable security arrangements had been made to protect the Personal Data Sets despite the vulnerability. Encryption of the Personal Data Sets had prevented unauthorised access by third parties. 12 However, insufficient protection was accorded to the KYC documents. The Organisation had only performed standard functional tests of the Website prior to launching it. No penetration test or web application vulnerability scan was conducted. Had these tests and scans been performed on the Website, the well-known vulnerability could be easily detected. 13 Given the type of personal data that the KYC documents contained, it is unreasonable that the Organisation had omitted the abovementioned security testing prior to the Website launch. The ease with which the vulnerability could be exploited via changing the last few numbers of the URL made this more egregious. 14 The Commissioner therefore finds the Organisation in breach of section 24 of the PDPA. The Commissioner’s Directions 15 Given the Commissioner’s findings that the Organisation is in breach of section 24 of the PDPA, the Commissioner is empowered under section 29 of the PDPA to issue the Organisation such directions as it deems fit to ensure compliance with the PDPA. This may include directing the Organisation to pay a financial penalty of such amount not exceeding S$1 million. 4 InfoCorp Technologies Pte. Ltd. 16 [2019] SGPDPC 17 In assessing the breach and determining the directions, if any, to be imposed on the Organisation in this case, the Commissioner took into account the following mitigating factors: (a) The URL was only known to Participants at the material time and not to the public. (b) The KYC documents were only downloaded by a small number of Participants. (c) The exposure was for a very short time window of about 15 minutes. (d) The Organisation had taken immediate remedial actions to prevent further unauthorised access of the KYC documents. (e) The Organisation was cooperative during the investigation. (f) The Organisation had promptly notified the PDPC of the incident. 17 The Commissioner hereby directs the Organisation to pay a financial penalty of S$6,000 within 30 days from the date of the Commissioner’s direction, failing which, interest at the rate specified in the Rules of Court 2 in respect of judgement debts, shall accrue and be payable on the outstanding amount of the financial penalty until the financial penalty is paid in full. YEONG ZEE KIN DEPUTY COMMISSIONER FOR COMMISSIONER FOR PERSONAL DATA PROTECTION 2 Cap 322, R5, 2014 Rev Ed. 5 ",Financial Penalty,2b7e4b3d76547b65e3ffb56aa9d289d4a9afa901,"[""pdf-content"",""timestamp"",""decision"",""pdf-url"",""tags"",""nature"",""url"",""title"",""date"",""description""]"