_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,90,90,1,952,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,"[""pdf-content"",""timestamp"",""decision"",""pdf-url"",""tags"",""nature"",""url"",""title"",""date"",""description""]" 2023-10-01T11:02:10+08:00,fbd32491db44d3d0c97aa12a99cefd61ec954264,91,91,1,952,"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,"[""pdf-content"",""timestamp"",""decision"",""pdf-url"",""tags"",""nature"",""url"",""title"",""date"",""description""]" 2023-10-01T11:02:10+08:00,fbd32491db44d3d0c97aa12a99cefd61ec954264,92,92,1,952,"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,"[""pdf-content"",""timestamp"",""decision"",""pdf-url"",""tags"",""nature"",""url"",""title"",""date"",""description""]" 2023-10-01T11:02:10+08:00,fbd32491db44d3d0c97aa12a99cefd61ec954264,93,93,1,952,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,"[""pdf-content"",""timestamp"",""decision"",""pdf-url"",""tags"",""nature"",""url"",""title"",""date"",""description""]" 2023-10-01T11:02:10+08:00,fbd32491db44d3d0c97aa12a99cefd61ec954264,94,94,1,952,"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,"[""pdf-content"",""timestamp"",""decision"",""pdf-url"",""tags"",""nature"",""url"",""title"",""date"",""description""]"