Fines for PDPA Breaches: How Clear is the Crystal Ball?

The Singapore Personal Data Protection Commission ("PDPC") has recently issued a number of new enforcement decisions.

These decisions were made in relation to breaches by organisations of their protection obligation under section 24 of the Personal Data Protection Act 2012 ("PDPA") to protect personal data in its possession or under its control, by making reasonable security arrangements to prevent unauthorised access, collection, use, disclosure, copying, modification, disposal, or similar risks ("Protection Obligation").

Interestingly, while a fine of S$74,400 was imposed on E-Commerce Enablers Pte. Ltd. ("ShopBack"), much lower fines of S$9,000 and S$3,000 were imposed on smaller businesses Century Evergreen Private Limited ("Century Evergreen") and Autobahn Rent A Car Pte. Ltd. ("Autobahn") despite similar breaches having been found in all three cases. These decisions demonstrate the PDPC's practice of imposing proportional financial penalties based on, in particular, an organisation's turnover.

In this article, we will look at some of the factors considered when determining the quantum of financial penalty to be imposed under the PDPA. We will then compare this with the process in Europe and try to answer the question of whether more can be done to make the process more transparent and predictable for companies.

The facts and findings in recent cases

We will start by considering the facts of three recent cases.

E-Commerce Enablers Pte. Ltd. [2023] SGPDPC 6

ShopBack runs an online platform offering inter alia cashback for purchases made through affiliated merchant programs, as well as coupons and voucher codes. At the relevant time, ShopBack hosted its customer database on virtual services in an Amazon Web Services ("AWS") cloud environment, and employed a team ("SRE Team") whose responsibilities included managing an AWS access key with full administrative privileges ("AWS Key"). Only members of the SRE Team were supposed to have access to the AWS Key which is supposed to be deleted and replaced from time to time. However, on 4 June 2019, the AWS Key was inadvertently committed to software code in a private repository on GitHub by a senior member of the SRE Team ("Compromised Key"). GitHub is a platform and cloud-based service for software development and version control using Git, a distributed version control system, which allows developers to store and manage their code. Although this was discovered two days later by another SRE Team member who immediately removed the Compromised Key from the repository on GitHub, the Compromised Key remained accessible by third parties in GitHub's 'commit' history', which records all changes and previous versions of code uploaded on GitHub.

On 21 June 2019, 15 days after the Compromised Key was inadvertently committed to GitHub, the Compromised Key was to be deleted and replaced by a new key as part of an out-of-cycle key rotation. If this had been done, a third party would not have been able to use the Compromised Key to access ShopBack's AWS Environment. However, the Compromised Key was never deleted. As such the Compromised Key continued to be usable to access ShopBack's AWS environment (and ShopBack's customer storage servers) for the next 15 months or so. On 9 September 2020, a threat actor accessed ShopBack's AWS environment by using the Compromised Key, which had likely been obtained from the commit history of the GitHub private repository. The threat actor then exfiltrated the personal data belonging to a substantial number of users, including the personal identity card ("NRIC") numbers of 9,961 affected users, bank account number of 299,381 users and email addresses of 1,457,637 affecter users. ShopBack discovered the security breach on 17 September 2020 during a routine security review and implemented remedial measures. On 12 November 2020, this personal information obtained from ShopBack was offered for sale on Raidforums, an online cybersecurity forum commonly used for trading and selling of stolen databases.

Although ShopBack sought to frame the incident as a one-off case of human error, and not the result of a systemic issue with ShopBack's security practices, this was rejected by the PDPC. The PDPC reiterated its position that organisations cannot place sole reliance on their employees to perform their duties properly as a security arrangement to protect personal data. Instead, the PDPC was of the view that there must be some processes in place to ensure that employees do in fact carry out their duties, such as independent verification by another checker. ShopBack was found to lack sufficiently robust processes for the management of AWS keys, and that additional verifications and checks should be in place for such high-risk task.

Century Evergreen Private Limited [2023] SGPDPCS 5

Century Evergreen is a manpower contracting services company. It requires jobseekers to submit their identification documents for the verification of the jobseeker's identity. Due to an Insecure Direct Object References ("IDOR") vulnerability on its website since 2015, 96,889 images of identification documents belonging to 23,940 individuals (including NRICs) were downloaded from the Organisation’s website by an unauthorised third party between 10 to 12 December 2022.

Century Evergreen was found to have breached the Protection Obligation by failing to include any security requirements to protect personal data in its contract with its IT vendor who first developed and subsequently maintained the website. The PDPC emphasised that even though Century Evergreen had engaged an IT vendor, it remained solely responsible for protecting the personal data in its possession and control at all material times. The PDPC reviewed Century Evergreen's contract with its IT vendor and concludedthat there was a glaring omission of clauses requiring the IT vendor to implement security protocols to protect personal data, and that there were also no arrangements with the IT vendor for the conduct of any security tests whether prior to or after the launch of the website.

Autobahn Rent A Car Pte. Ltd. [2023] SGPDPCS 4

Autobahn operates the car sharing service Shariot in Singapore. On 24 September 2022, Autobahn received customer feedback that a photograph on its mobile application had been replaced with a pornographic photograph. It subsequently discovered that the offending photograph had been uploaded through an unrevoked administrator account belonging to an ex-employee. A hacker who accessed the ex-employee's personal laptop without authorisation was able to log into Shariot's backend admin web portal through the ex-employee's unrevoked account. This in turn enabled unauthorised access to and exfiltration of 53,000 personal data sets of Shariot users, with the personal data affected in the incident including names, email addresses, mobile phone numbers, NRIC numbers and general location data. Subsequently on 21 October 2022, Autobahn was alerted of a cybercrime forum post offering the sale of a Shariot database containing personal data.

Following investigations by the PDPC, Autobahn was found to have failed to implement and ensure reasonable access control to its backend admin web portal, on the basis that Autobahn failed to revoke the login credentials of an administrator account belonging to a former employee who had left the organisation a few months earlier, as well as failed to implement multi-factor authentication ("MFA") as an additional access control for administrator accounts that had access to its sizeable user database. The PDPC highlighted the need for organisations to implement enhanced access controls, such as the use of a one-time password ("OTP"), in respect of accounts that are granted access rights to sensitive personal data records or a significant volume of personal data.

The determination of financial penalties under the PDPA and recent local examples

Section 48J(1) allows the PDPC to impose a financial penalty on an organisation who is found to have intentionally or negligently contravened its obligations under the PDPA. The maximum fine which can be imposed on an organisation is SGD1 million or 10% of that organisation's annual turnover, whichever is higher. Section 48J(6) sets out a list of factors that the PDPC must have regard to in determining the amount of a financial penalty imposed on an organisation, including the following:

• The nature, gravity and duration of the non-compliance by the organisation;
• The type and nature of the personal data affected by the non-compliance by the organisation;
• Whether the organisation took any action to mitigate the effects and consequences of the non‑compliance, and the timeliness and effectiveness of that action;
• Whether the financial penalty to be imposed is proportionate and effective, having regard to achieving compliance and deterring non‑compliance with the PDPA
• The likely impact of the imposition of the financial penalty on the organisation, including the ability of the organisation or person to continue the usual activities of the organisation or person; and
• Any other matter that may be relevant.

Notably the PDPC is entitled to give such weight to each factor as it considers appropriate and there is no further published guidance as to how a financial penalty is to be determined. This in effect gives the PDPC a great deal of discretion in determining the quantum of financial penalty to impose on an organisation that it considers as proportionate and effective to ensure compliance and deter non-compliance with the PDPA.

The fines issued by the PDPC in a few recent cases as well as the factors which were taken into consideration, are set out below.

A comparison with the GDPR position

Apart from listing the factors considered, none of the cases go into detail as to how the fine levied had been calculated. While the PDPC considered the annual turnover of the organisations involved, those figures were not disclosed in the published judgments. As such, we cannot determine the proportion of the annual turnover the quantum of the fine constituted.

In contrast, the calculation of fines under the General Data Protection Regulation ("GDPR") is somewhat easier to predict, thanks to Guidelines 04/22 on the calculation of administrative fines under the GDPR ("Guidelines").

The Guidelines outline a detailed five-step methodology for calculating a starting point sum for a fine, and also explain how to determine the turnover of an undertaking. Under the Guidelines, the starting point sum for a GDPR fine ("Starting Point Sum") is calculated as a percentage of the maximum fine which currently, depending on which article has been breached, may be (a) the higher of €10m or 2% of the undertaking’s annual turnover, or (b) the higher of €20m or 4% of the undertaking’s annual turnover. Depending on the seriousness of the infringement, the Starting Point Sum is set at a different percentage of the maximum fine, set out in the below table:

The Guidelines allow for a potential reduction of the Starting Point Sum based on turnover. For example, if the annual turnover of an organisation is less than two million Euros, the starting amount of the fine may be lowered to 0.2% of the Starting Point Sum above. The Guidelines however make it clear that the supervisory authority is not obliged to reduce the starting sum based on turnover, and that if it does, may opt to reduce the sum only partially.

It is only after the starting amount is determined that mitigating and aggravating factors are considered and applied to reduce or increase the starting amount of fine that was earlier determined.

Conclusion

The Guidelines enable parties facing a potential GDPR fine to be better advised as to how much that penalty is likely to be. While parties facing financial penalties under the PDPA can rest assured that they are unlikely to be financially crippled, more transparency as to how the penalties are quantified would help an organisation better manage its finances while not affecting the objectives of the penalty.