1 This dispute arose over the misconfiguration of a server file, which in turn led to a leak of Razer’s non-public customer data. The plaintiff brings claims in contract and negligence against the defendant, its information technology consultant.

2 The plaintiff, Razer (Asia-Pacific) Pte Ltd (“Razer”) is a company incorporated in Singapore. It is in the business of high-performance gaming hardware, software, services and systems, financial technology services and digital payments. ¹

3 The defendant, Capgemini Singapore Pte Ltd (“Capgemini”) is a professional services firm incorporated in Singapore. It provides information technology consultancy services. ²

4 On 1 March 2019, Razer engaged WhiteSky Labs (Singapore) Pte Ltd (“WSL”) as Razer’s information technology consultant to assist with the upgrade of Razer’s digital commerce platform. In or around March 2020, Capgemini acquired WSL. On 1 June 2020, Capgemini became a party to the consulting services agreement (“CSA”) between Razer and WSL, and assumed all obligations owed by WSL to Razer. ³

5 In 2018, Razer embarked on a re-platforming initiative, Project Phoenix, under which it aimed to upgrade its e-commerce platform from Hybris 5.7 to the SAP Commerce Cloud. ⁴ As part of Project Phoenix, Razer needed to integrate SAP Commerce Cloud to various third-party applications used by Razer’s business team. This would be done by way of an Application Programming Interface platform (“API”) known as Mulesoft, which would enable different applications to communicate with each other. ⁵ I will henceforth refer to the process of integrating SAP Commerce Cloud to Razer’s third-party applications as the Mulesoft integration.

6 Razer engaged WSL for the Mulesoft integration as they were the top Mulesoft solution partner of the year. ⁶ Razer and WSL entered the CSA on 1 March 2019. It is undisputed that the CSA acted as a sort of a master agreement, and that statements of work (“SOW”) detailing the services required at different stages of Project Phoenix were subsequently issued as Project Phoenix progressed. ⁷ I say more about agreements entered into by Razer and WSL below.

7 In or around late 2019 or early 2020, Capgemini recommended that Razer install, utilise and integrate into its information technology environment a technology stack (the “ELK Stack”) comprising the following applications:

(a) Elasticsearch: an open source search and analytics engine;

(b) Logstash: a data processing pipeline for Elasticsearch; and

(c) Kibana: an application which provides search, viewing, analysis and data visualisation capabilities for data stored and indexed in Elasticsearch. ⁸

8 As mentioned above at [6], the CSA was entered into between Razer and WSL and effective as of 1 March 2019. Under cll 1.1 and 1.2 of the CSA, Razer retained WSL to perform consulting services. These consulting services and any additional services would be detailed in subsequent SOWs, which would be subject to terms and conditions set out in the CSA. ⁹

9 Under cl 3(ii), WSL warranted that its services to Razer would be performed:

10 As mentioned (above at [8]), the services detailed in the SOWs formed part of WSL’s obligations under the CSA. Three SOWs are of especial importance to the present suit.

11 On 5 February 2020, Razer and WSL entered into an SOW for “Project Phoenix – ELK Reporting DB & API” (“the February 2020 SOW”). ¹¹ Essentially, the Razer commerce team required access to data on the customer orders which were transacted and managed via Razer’s digital commerce channels. Previously, this data was reported directly from an offline copy of its eCommerce platform database. This would no longer be possible after the migration of the eCommerce platform as part of Project Phoenix.

12 WSL was hence engaged to create the capability to expose digital transaction data relating to customer orders to a business reporting strategy. This was to be done through implementing and configuring the ELK stack to log and query data, and implementing and configuring an additional Mulesoft API to expose the filtered data to consumers and to post this data into a data store. ¹²

13 On 9 April 2020, Razer and WSL entered into an SOW for “Adaptive Managed Services” (“the April 2020 SOW”). ¹³ WSL was to provide Razer with a one-year adaptive service for solutions deployed on the Mulesoft platform. ¹⁴ This included (inter alia) the provision of support and maintenance, governance over the Mulesoft platform and API services implemented on it, monthly reporting and support engineers who were experienced and 100% certified Mulesoft developers.

14 On 18 May 2020, Razer and WSL entered an SOW for “Mulesoft Project Resource Support” (the “May 2020 SOW”). ¹⁵ Resources provided by WSL (ie, two Mulesoft consultants – namely, a technical architect and a developer) would work under the management and direction of Razer’s Project Managers. ¹⁶

15 On 20 March 2019, Razer and WSL entered into a Data Processing Addendum (“DPA”). ¹⁷ The DPA formed part of the agreement between them ¹⁸ and highlighted WSL’s obligations with respect to personal data made available to WSL in the course of its provision of services to Razer and/or entities controlled by Razer. ¹⁹

16 Mr Argel Cabalag (“Mr Cabalag”) had been employed by WSL as a Senior Consultant on 15 July 2019. On or about March 2020, his contract of employment with WSL was novated to Capgemini following Capgemini’s acquisition of WSL. ²⁰ It is undisputed that Mr Cabalag is the technical architect provided by WSL under the May 2020 SOW. ²¹

17 On or about 7 April 2020, Razer provided Mr Cabalag with administrative user credentials (the “Admin Credentials”) to two of Razer’s servers, the Elasticsearch server and the Kibana server. The Admin Credentials allowed users to access and modify the security settings of the Elasticsearch server, the Kibana server and their respective applications. ²²

18 After Capgemini’s acquisition of WSL in March 2020, WSL, Capgemini and Razer entered into a Deed of Novation. ²³ Pursuant to this Deed of Novation and with effect from 1 June 2020, Razer released WSL from its liabilities, obligations, claims and demands under the CSA and Capgemini was substituted in place of WSL as party to the CSA. ²⁴ Going forward, I will refer to all novated agreements between Razer and WSL as agreements between Razer and Capgemini.

19 On or about 15 June 2020, Mr Pradeep Annaiah (“Mr Pradeep”), a Project Manager employed by Razer at the material time, was unable to log into and access the Kibana server and/or its application (the “Login Problem”). ²⁵ Mr Pradeep contacted Mr Terrence Chia, a Senior Systems Engineer at Razer, ²⁶ and Mr Ryan Lua, an IT Manager in Razer’s IT Infrastructure Team, ²⁷ to ask them to check on the Login Problem. ²⁸ Mr Terrence Chia replied on the same day stating that he would attempt to reboot the server. ²⁹ He was not successful in resolving the Login Problem. ³⁰ On 16 June 2020, Mr Pradeep then raised a support ticket with Capgemini to seek Capgemini’s assistance. ³¹

20 On 17 June 2020, Mr Terrence Chia emailed Mr Pradeep that he would have to “trouble shoot with your vendor”. ³² Ms Neoh Su Ping (“Ms Neoh”), an IT Director in the IT Application Team at Razer, was copied in this email. Shortly after on the same day, Ms Neoh emailed Mr Cabalag asking if he would “be able to shed some light” on the Login Problem. ³³

21 Mr Cabalag proceeded to work on the matter and on 18 June 2020, he sent a WhatsApp message to Ms Neoh and later, an email to Razer’s IT Infrastructure Team, to inform that he had resolved the Login Problem. ³⁴ With that, the Login problem appeared to have been resolved.

22 On 19 August 2020, one Mr Bob Diachenko (“Mr Diachenko:”) contacted Razer’s Support team stating that he was “trying to get hold of someone on [Razer’s] IT team” and that this was an “alert (responsible disclosure) of a security issue” (the “August Communication”). He stated that he had come across an “unprotected, publicly available database instance which seems to be part of Razer cloud infrastructure and contains non-public information” such as “customers [sic] details, emails, order information and much more”. ³⁵ This leak of non-public information relating to Razer’s customers will hereafter be referred to as the Data Leak.

23 On 22 August 2022, Mr Scott Keathley (“Mr Keathley”), Senior Manager of Customer Service at Razer, emailed Razer’s Cyber Security and Compliance Process Architect, Ms Tiong Lee Lan (“Ms Tiong”), ³⁶ regarding Mr Diachenko’s message. Mr Keathley stated that they had told Mr Diachenko to contact Hackerone Inc. For context, Hackerone Inc was an external vendor which facilitated Razer’s bounty programme, under which individuals could report vulnerabilities and bugs in Razer’s IT systems and products for monetary compensation. ³⁷ Ms Tiong agreed that Mr Diachenko should report the issue via the bounty programme. ³⁸

24 On 24 August 2022, Mr Keathley then informed Ms Tiong that Mr Diachenko had found that the HackerOne Inc link was disabled. Ms Tiong initially maintained that the only way Razer could pay any bounty was if a report was submitted via Hackerone Inc’s website. However, she later clarified that Razer was transiting to another programme, Cesppa, and there was no bounty programme in the interim period before Cesppa was up and running. ³⁹ Mr Keathley informed Ms Tiong that Mr Diachenko appeared to want to submit his feedback as soon as possible and asked whether his agents could provide an approved statement to Mr Diachenko if there was no site available for the feedback to be submitted. ⁴⁰

25 Subsequent to Ms Tiong’s instructions, ⁴¹ the following response was provided to Mr Diachenko on 26 August 2020 by Ms Racquel Tamiok of the Razer VIP Response Team:

26 In response, Mr Diachenko stated on 27 August 2020:

27 On 10 September 2020, Mr Diachenko published an article on Linkedin titled “Thousands of Razer customers order and shipping details exposed on the web without password”. ⁴³ He stated that the information was “part of a large log chunk stored on a company's Elasticsearch cluster misconfigured for public access since August 18th, 2020”, and that while he had notified Razer of the exposure via their support channel, his message was processed by non-technical support managers. The article was updated on 11 September 2020 with a comment by Razer stating that they were made aware by Mr Diachenko of a server misconfiguration that potentially exposed order details, customer and shipping information, and that the server misconfiguration had been fixed on 9 September 2020 prior to the lapse being made public.

28 Following Mr Diachenko’s Linkedin article, the Data Leak received media coverage on multiple websites including The Straits Times, PC Gamer, Ars Technica, C Net, Yahoo Finance, etc over the course of September 2020. ⁴⁴

29 Razer’s position is that Capgemini, acting through Mr Cabalag, was responsible for the disabling of security settings of Razer’s Kibana application (“the Security Incident”). ⁴⁵ When assisting Razer to troubleshoot and resolve the Login Problem on 18 June 2020, Mr Cabalag added “#” (the “Misconfiguration”) in a configuration file located in the Elasticsearch server (“the Elasticsearch Configuration File”) which controlled security and access to the Kibana application. This Misconfiguration allowed unauthenticated access into the Kibana application. ⁴⁶ After being informed of the Security Incident on 9 September 2020 and agreeing to help resolve the incident, Mr Cabalag resolved the Security Incident on or about 10 September 2020 by removing the “#” command and thereby reinstating the security settings of the Kibana application. ⁴⁷

30 Capgemini initially pleaded in its defence that while Mr Cabalag had access to the Admin Credentials, Mr Cabalag had not performed the Misconfiguration. Capgemini’s position was that the presence of new IP addresses set up by Razer could have been the cause of the misconfiguration of the security settings of the Kibana application. ⁴⁸

31 However, on the sixth day of trial, Mr Cabalag admitted that he had been the one who had done the Misconfiguration. According to counsel for Capgemini, they had written to counsel for Razer on 28 June 2022 to request for copies of snapshots of Razer’s servers which had been referred to in Razer’s technical expert witness’ report. Following several requests for the snapshots made by Capgemini, Capgemini applied on the first day of trial for snapshots reviewed by Razer’s technical expert witness to be made available to Capgemini’s expert witnesses as well. On 14 July 2022, these snapshots were received by counsel for Capgemini. Counsel for Capgemini then showed Mr Cabalag the report prepared by Razer’s technical expert witness as well as the snapshots. ⁴⁹ Following this, Mr Cabalag made the following statement to clarify various paragraphs which he wished to amend in his affidavit evidence-in-chief (“AEIC”): ⁵⁰

32 As such, the question of who had performed the Misconfiguration of the Elasticsearch Configuration File is no longer a point of dispute.

33 Razer avers that Capgemini owed the following contractual duties to Razer: ⁵¹

(a) To provide Razer with day-to-day operational management and ongoing support, assistance and maintenance of Razer’s MuleSoft environment and any related information technology issues faced by Razer from time to time including, inter alia, login and any other issues with the Kibana and Elasticsearch servers and/or their applications.

(b) To ensure that its personnel (including Mr Cabalag) had the appropriate and adequate skill, qualifications and experience.

(c) To ensure that the security configurations of Razer’s Kibana and Elasticsearch servers and/or their applications (including any configuration files contained therein) were not misconfigured and were enabled and functioning properly.

(d) To protect against (and to not insert) any harmful code that might disrupt, disable, harm or otherwise impede Razer’s operations, including but not limited to code which had the effect of disabling the security configuration of Razer’s Kibana and Elasticsearch servers and/or their applications.

(e) To take, inter alia, appropriate technical measures to ensure the security, including but not limited to the confidentiality, integrity and resilience, of Razer’s Kibana and Elasticsearch servers and/or their applications and protect against unauthorised access to, inter alia, information and data relating or belonging to Razer’s customers.

(f) To exercise reasonable care, skill and diligence expected of an international firm or service provider.

34 Razer’s position is that Capgemini has breached the express terms of the agreements between them, including cl 3(ii) of the CSA, sections 2.2, 2.3 and 4.2.1 of the 9 April SOW and cl 7 of the DPA. ⁵² Capgemini failed to ensure that Mr Cabalag had the appropriate skill, qualifications and experience necessary to properly assist Razer with the Login Problem. It had also (through Mr Cabalag) failed to protect against and to not insert harmful code that would disrupt, disable, harm or otherwise impede Razer’s operations and to take appropriate technical measures to ensure the security of Razer’s Kibana and Elasticsearch servers and/or their applications and protect against unauthorised access to, inter alia, information and data relating or belonging to Razer’s customers. It also failed (through Mr Cabalag) to exercise reasonable care, skill and diligence expected of an international firm of service provider when assisting Razer with the Login Problem. ⁵³

35 Razer also avers that Capgemini had breached the following implied contractual duties owed to itself when assisting Razer to troubleshoot and resolve the Login Problem: ⁵⁴

(a) To exercise the requisite skill and care expected, which caused the security settings of the Kibana application to be disabled.

(b) To ensure that the security configuration of Razer’s Kibana application was functioning properly at all times between 18 June 2020 and 9 September 2020.

(c) To ensure that it did not misconfigure and/or disable the security settings of Razer’s Kibana and Elasticsearch servers and/or applications.

36 Razer avers that Capgemini’s breaches of the express and/or implied terms of the agreements caused the Data Leak between 18 June 2020 to 9 September 2020. This caused Razer to suffer, inter alia, reputational damage by reason of negative press coverage of the incident, causing the sales revenue of its e-commerce platform, Razer.com, to decrease significantly. ⁵⁵

37 Razer also relies on cl 12 of the CSA which states: ⁵⁶

38 Razer relies on cl 12 of the DPA as well, whereby Capgemini agreed to indemnify Razer against losses, damages, costs or expenses (including legal fees) incurred by Razer arising out of or in connection with Capgemini’s breach of the DPA, Capgemini’s negligence or wilful misconduct, or any Security Incident. ⁵⁷

39 Razer also pleads that further or alternatively, Capgemini was negligent when assisting Razer to resolve the Login Problem on 18 June 2020, ⁵⁸ and/or that Capgemini was vicariously liable for the injury, loss and damage sustained as a result of Mr Cabalag’s negligence. ⁵⁹

40 These breaches of the express and implied terms caused serious damage to Razer’s reputation by reason of, inter alia, negative press coverage regarding the Security Incident. This negative press coverage caused Razer to suffer loss of profits and loss of chance to secure potential business opportunities. ⁶⁰

41 Razer hence claims:

(a) Damages, including special damages, to be assessed.

(b) A declaration that the Plaintiff be fully indemnified by the Defendant for all damages, losses and expenses incurred and which the Plaintiff may incur as a result of the Security Incident.

(c)  Interest.

(d)  Costs on an indemnity basis.

(e)  Such further and other relief as this Honourable Court deems fit.

42 Capgemini’s position is that none of the SOWs entered into under the CSA (including the February 2020 and April 2020 SOWs) related to the upgrading of Razer’s digital commerce platform. ⁶¹ Under the February 2020 SOW, the implementation and configuration of the ELK Stack was excluded from the scope of its duties under cll 1.3 and 2.6 (the “Scope Exclusions”). ⁶²

43 For the April 2020 SOW, managed services to be provided relating to Kibana would include only API and runtime logs and were subject to Razer’s compliance with customer responsibilities including maintaining its internal IT environment. Capgemini avers that its duty pursuant to the April 2020 SOW did not extend to “ongoing support, assistance and maintenance of [Razer’s] MuleSoft environment and any related information technology issues faced by [Razer]”. ⁶³ In addition, Capgemini pleads that it did not have the duty to ensure that the security configurations of Razer’s Kibana and Elasticsearch servers and/or their applications were not misconfigured or to manage Razer’s operations, including code which had the effect of disabling said security configurations. Pursuant to cll 2.6 and 2.7 of the April 2020 SOW, this was Razer’s express duty and responsibility. ⁶⁴ Further, no ticket was raised with regard to the April 2020 SOW so as to trigger these managed services. ⁶⁵

44 Capgemini’s position is that any services provided by Mr Cabalag for the Login Problem and during September 2020 fell within the scope of the May 2020 SOW. ⁶⁶ For the May 2020 SOW, Capgemini avers that it was engaged to provide resource augmentation services, where resources it provided to Razer would work under the management and direction of Mr Pradeep. ⁶⁷

45 Further, Capgemini avers that even if it is held liable for any breach of the agreements, Razer had failed to mitigate its losses by failing to take reasonable steps in response to Mr Diachenko’s August Communication. ⁶⁸ In the event Capgemini is held negligent or vicariously liable for Mr Cabalag’s negligence, Capgemini avers that any damage suffered by Razer must take into account Razer’s contributory negligence for its delay in taking action to respond to the August Communication. ⁶⁹

46 Against the backdrop of Mr Cabalag’s statement that he had performed the Misconfiguration, the following issues present themselves for my consideration:

(a) Whether Capgemini had breached its contractual obligations to Razer in respect of Mr Cabalag’s troubleshooting of the Login Problem.

(b) Whether Capgemini was negligent in respect of Mr Cabalag’s troubleshooting of the Login Problem.

(c) Whether any defences arose in Capgemini’s favour.

(d) The damages accruing from the Misconfiguration and Security Incident.

47 Razer submits that Capgemini was obliged to troubleshoot the Login Problem pursuant to the April 2020 and/or May 2020 SOWs. ⁷⁰ Alternatively, it had assumed responsibility to troubleshoot the Login Problem when it made the decision to bill Razer for its troubleshooting work. ⁷¹

48 Razer further submits that as long as Capgemini was obliged to troubleshoot the Login Problem under the April 2020 and/or May 2020 SOWs or under its assumed responsibility, then it would either be obliged to carry out its work in accordance with cl 3 of the CSA, or in accordance with an implied responsibility to exercise reasonable skill and care in carrying out its work. ⁷² As Mr Cabalag had caused the data breach in his capacity as a Capgemini employee, Capgemini would have breached cl 3 of the CSA as it did not exercise reasonable skill and care in carrying out its work. ⁷³ Alternatively, Capgemini would have breached its implied obligation to exercise reasonable skill and care in rendering services to Razer. ⁷⁴

49 Separately, Razer also submits that Capgemini has breached its data protection obligations under cl 7 of the DPA. ⁷⁵

50 On the other hand, Capgemini submits that the Login Problem did not fall under the scope of work envisioned or included in the agreements between the parties. ⁷⁶ Razer was the one responsible for maintaining the ELK Stack. The Login Problem falls within Razer’s responsibility as the inability of the Mulesoft APIs to connect to the ELK Stack ultimately relates to the failure of the ELK Stack to work. ⁷⁷

51 Mr Cabalag’s work hence fell only within the scope of the May 2020 SOW, which Capgemini characterises as a secondment contract pursuant to which Razer had full control of Mr Cabalag’s work, with the caveat that Mr Cabalag was not qualified for non-Mulesoft work and, for which Mr Cabalag was Razer’s agent for all works instructed to or delegated to him by Razer. ⁷⁸ While Mr Cabalag’s actions fell within the scope of the May 2020 SOW, they did not constitute a breach of the May 2020 SOW as the Scope Exclusions in the May 2020 SOW had put Razer on notice that Mr Cabalag had expertise only in Mulesoft and not in relation to non-Mulesoft skills. Therefore, Capgemini posits that Razer had instructed Mr Cabalag to troubleshoot the Login Problem –a non-Mulesoft-related problem – at its own risk. ⁷⁹

52 Further, Capgemini submits that any billing which Mr Cabalag had done for the Login Problem did not constitute an assumption of contractual responsibility but was consistent with the arrangement under the 18 May SOW, where Mr Cabalag would receive remuneration and salary while Razer managed, directed, and took responsibility for Mr Cabalag’s work. ⁸⁰

53 Capgemini also submits that Mr Cabalag’s actions in relation to the Login Problem did not breach the CSA as Capgemini’s team was sufficiently qualified and experienced with working knowledge of the ELK Stack. ⁸¹ Neither did his actions constitute a breach of any implied obligations, as there is no such implied obligation given the presence of an express obligation providing for standards of reasonable skill and care in cl 3(ii)(a) of the CSA. ⁸² There was also no breach of the DPA as the clauses cited by Razer pertain to the security of personal data within Capgemini’s system, whereas Razer’s personal data was never stored in Capgemini’s system. ⁸³

54 The principles of contractual interpretation are well-established in case-law and have been succinctly summarised by the Singapore Court of Appeal (“SGCA”) in CIFG Special Assets Capital I Ltd (formerly known as Diamond Kendall Limited) v Ong Puay Koon and others and another appeal [2018] 1 SLR 170 at [19]:

55 Further, due consideration is given to the commercial purpose of the transaction and why a particular obligation was undertaken. While the commercial purpose is not to be pursued at all costs, there is no reason to disregard it when it accords with the parties’ objective intentions: MCH International Pte Ltd and others v YG Group Pte Ltd and others and other appeals [2019] 2 SLR 837 at [26].

56 I find that Mr Cabalag had been contractually obliged to carry out work on the Login Problem under the April 2020 SOW, and that the manner in which he had carried out this work is in breach of cl 3 of the CSA and cl 7 of the DPA. I set out my reasons below.

57 Under cl 2.2 of the April 2020 SOW, Capgemini was to provide a managed service for “Razer existing MuleSoft environment”. ⁸⁴ Parties disagree on what the “Mulesoft environment” entails. While Razer posits that Capgemini was obliged to troubleshoot the Login Problem, ⁸⁵ Capgemini argues that the “Mulesoft environment” was intended to exclude configuration of the ELK stack ⁸⁶ as Capgemini’s responsibility was to configure the ELK Stack only insofar as it was necessary to connect the ELK Stack to the Mulesoft APIs. ⁸⁷

58 The parties place emphasis on different clauses in the April 2020 SOW. Razer draws attention to cll 2.3 and 4.2.1 of the April 2020 SOW. ⁸⁸ These clauses state that the managed services which Capgemini had agreed to provid included “incident management”, “problem management” and “high severity incident management”. ⁸⁹ The incident management services entail “ensuring that normal service operation is restored as quickly as possible” and include “troubleshooting, diagnosing, reproducing … [incidents] to devise a resolution”. ⁹⁰ As for problem management, problems are defined as “an unknown underlying cause of one or more incidents”, and problem management entails “troubleshooting, diagnosing, reproducing … [problems] to devise a resolution” and producing a “Root Cause Analysis, detailing … the identified cause of the problem [and] potential workarounds or permanent fix that will resolve the problem”. ⁹¹ Capgemini in turn draws attention to cl 4.5 of the April 2020 SOW, which excludes it from providing non-Mulesoft software support, upgrades, installations or configurations”. ⁹²

59 However, the fundamental question is what parties understood as the “Mulesoft environment”. Without a conclusive answer on this point, it is impossible to arrive at a finding of what parties had contemplated as the incidents and problems that Capgemini was obliged to manage or the “non-Mulesoft” issues that would be excluded from its responsibilities.

60 As the April 2020 SOW does not stand alone but forms part of a suite of agreements which facilitated the parties’ working relationship over the course of Project Phoenix, I find it helpful to turn to the February 2020 SOW to understand what parties considered the Mulesoft environment to be. Razer submits that in the February 2020 SOW, the Mulesoft environment was already contemplated as including the ELK Stack. ⁹³ This is because the ELK stack is “at the heart of the entire solution” and is hence included as part of the Mulesoft environment. ⁹⁴ This is evinced by cl 1.2 of the same SOW, which furnishes a diagram illustrating the “identified solution scope” that is to be implemented:

61 Indeed, the whole point of entering the February 2020 SOW was so that Razer could be privy to digital commerce transaction data, and as shown in the “technical scope” laid out at cl 1.2, this would be effected via a two-part solution whereby the ELK stack would first query data extracted from the Mulesoft transactional data logs, and then an additional Mulesoft API would expose the “filtered” data to consumers and store the data. In other words, the functioning of the ELK stack is fully embedded within the Mulesoft environment, as it acts as both a receiver of unfiltered data from Mulesoft and a transferor of filtered data to Mulesoft. ⁹⁵ It is hence this interaction between ELK and Mulesoft that is central to achieving the aim of the February 2020 SOW, which in turn accords with the overarching purpose of Project Phoenix. To suggest that Capgemini is only concerned with connecting the ELK stack to the Mulesoft environment and nothing else appears to me to be unnecessarily splitting hairs, and it seems unlikely – and rather commercially implausible – that parties would have so narrowly delineated Capgemini’s duties in the May SOW considering the purpose of Project Phoenix and the technical scope of the February 2020 SOW.

62 The contrived nature of such a delineation of duties is made even clearer by Mr Douch Julian Philip’s (“Mr Douch”) confused and contradictory evidence on Mr Cabalag’s scope of work. In para13 of his AEIC, Mr Douch states that Mr Cabalag’s scope of work under the SOWs “was specific to the MuleSoft APIs and not to the ELK Stack. ⁹⁶ During cross-examination, however, he was shown and accepted that the solution represented in the diagram of the “identified solution scope” (see above at [60]) was the solution that was “recommended and provided by Capgemini to Razer. ⁹⁷ He was then questioned whether this meant that para 13 of his AEIC was untrue. He agreed and explained that: ⁹⁸

63 This appears to me to be the inevitable irony of seeking to confine the scope of Mr Cabalag’s work to just the connection of the ELK stack to Mulesoft APIs when the two elements are inextricably entwined under Project Phoenix. To limit Capgemini’s responsibilities in this fashion does not make sense given the context of what Project Phoenix is meant to achieve and cannot have been the commercial arrangement contemplated by Razer and Capgemini.

64 Capgemini’s contemporaneous conduct also casts doubt on Mr Douch’s position that Razer could not come to Capgemini under the February 2020 or April 2020 SOWs for the Login Problem. Mr Pradeep contacted the WSL Support Team on 16 June 2020 to request for assistance on the Login Problem, and the WSL Support Team promptly issued a ticket on 16 June 2020. ¹⁰⁰ Mr Douch has stated that should Capgemini agree to work on something that it was not legally obliged to perform, he would expect to see “a commercial agreement which would be at least a minimum in the form of a statement of work”, signed off by parties. ¹⁰¹ However, there is no evidence of any additional commercial agreement of such shape or form being entered into before the WSL Support Team’s issuance of a ticket. The logical conclusion from parties’ conduct is hence that addressing the Login Problem was indeed one of Capgemini’s existing contractual duties.

65 I hence find that the work carried out by Capgemini (specifically, by Mr Cabalag), fell under the April 2020 SOW.

66 As I have found that the assistance provided on the Login Problem fell within the scope of work intended by both parties under the April SOW, it is not necessary for me to consider Capgemini’s submission that Mr Cabalag’s assistance should be considered as part of his duties under the May 2020 SOW only. For completeness, however, I will address the submissions made on this point.

67 Capgemini submits that the scope exclusions had put Razer on notice that Mr Cabalag had expertise only in Mulesoft and not in relation to non-Mulesoft skills, such that Razer instructed Mr Cabalag to troubleshoot the non-Mulesoft Login Problem at its own risk. ¹⁰² The scope exclusions in the 18 May SOW are listed under Section 1.1 of the SOW as:

68 On the other hand, Razer's position is that Capgemini would still be responsible for technical work done by Mr Cabalag under the May 2020 SOW. ¹⁰³

69 I accept Razer’s view on this. As a starting point, given that I have found earlier that the operation of the ELK stack cannot be absolutely cleaved from the operation of the Mulesoft APIs, I do not find that Section 1.1 can be read as excluding the Login Problem.

70 More importantly, Mr Cabalag was not engaged as a chisel that would only move when the hammer strikes it. His engagement was as a technical architect and came with a package of skills that Razer was entitled to rely on and did. The rates which Razer paid for Mr Cabalag’s work were commensurate with this skill level, and not that of a casual worker.

71 In any event, besides my finding above regarding why the work done vis-à-vis the Login Problem is covered under the April 2020 SOW, there are three other reasons why the work could not have been covered under the May 2020 SOW only.

72 First, Mr Douch’s evidence on the stand was inconsistent with Capgemini’s pleaded position. At times, Mr Douch had stated that Mr Cabalag’s assistance for the Login Problem fell “outside of his roles and responsibilities for the statement of work on 18 May.” ¹⁰⁴ When confronted that his evidence differed from Capgemini’s pleaded position that Mr Cabalag’s assistance fell within the scope of services set out in the May 2020 SOW, Mr Douch explained that since Mr Cabalag was working as a Mulesoft consultant and under Razer’s direction, any assistance by Mr Cabalag for the Login Issue was provided under Razer’s guidance and outside of the May 2020 SOW. ¹⁰⁵ This explanation is unsatisfactory. For one, it still undermines Capgemini’s pleaded position that Mr Cabalag’s work was done within the scope of the May 2020 SOW. For another, Mr Douch was unable to point to any contractual clause to suggest that Razer was responsible for anything done for the Login Problem. ¹⁰⁶ Moreover, it is Mr Cabalag’s own evidence that he was ultimately working in the capacity of a WSL employee:

73 Capgemini then seeks to reconcile Mr Douch’s confounded explanation in its closing submissions by saying that Mr Douch’s point was that he considered Mr Cabalag’s actions to have fallen within the scope exclusions in the May 2020 SOW. ¹⁰⁸ I did not find this to be a convincing framing of Mr Douch’s evidence. In fact, nothing in either Mr Douch or Mr Cabalag’s conduct suggests that Capgemini considered Mr Cabalag’s work to be something Capgemini was not contractually responsible for.

74 On the contrary, when Mr Douch discovered that Mr Cabalag had been asked to assist on something which Mr Douch considered to “[cross] potentially the border of a contract”, ¹⁰⁹ Mr Douch’s evidence was that he had told Mr Cabalag that this was not something he was engaged to do, but that Mr Cabalag had said that he was supporting Pradeep’s team to “get something fixed in the context of their environment”. ¹¹⁰ Nothing was done following this alleged conversation, which suggests that Capgemini did not see any need to stop Mr Cabalag from assisting Razer in such fashion. Neither was Mr Douch able to furnish any evidence that he had told Razer that Razer was the one responsible for the work done on 18 June 2020. ¹¹¹

75 Tellingly, when Mr Cabalag’s timesheets ¹¹² for that period were shown to Mr Douch, Mr Douch also agreed that Capgemini had accepted that the work done on 17 June 2020 was billable to Razer, and that this work had not been described as something outside his roles and responsibilities under the April or May SOW or that he was not qualified to perform. ¹¹³ Similarly, Mr Cabalag agreed that he only entered his time sheets on the basis that whatever he entered would be billable to the client, ¹¹⁴ that the timesheets were used to show the work billed to Razer and that Razer was then billed for the work done in June. ¹¹⁵

76 On the evidence before me, there is hence little to show that the work done by Mr Cabalag for the Login Problem was covered under the May 2020 SOW, let alone covered under the May SOW to the exclusion of the other SOWs and agreements.

77 Second, even if the work was covered under the May 2020 SOW, the February, April and May 2020 SOWs are not mutually exclusive. It appears to me that the three SOWs complement and supplement each other in outlining Capgemini’s obligations to help set up the Mulesoft aspect of Project Phoenix. The February SOW was concerned with setting up the Mulesoft environment, ie, implementing and configuring the ELK stack and an additional Mulesoft API, the April SOW was concerned with provided managed services for the Mulesoft platform that had been set up, and the May SOW was concerned with supplying consultants such as Mr Cabalag for specified works. It is undisputed that the SOWs are to be read in tandem with each other and with the CSA as a master agreement from which the SOWs flow. Insofar as the April 2020 SOW is to lay out the managed services to be provided (as I have found above), while the May 2020 SOW is to lay out the obligation to provide personnel to work under the direction of Razer’s Project Managers, I see no reason why the personnel provided for the purposes of the May 2020 SOW may not be the same persons deployed to assist on services prescribed under the April 2020 SOW.

78 Third, even if the work was covered under the May 2020 SOW, the Scope Exclusions merely indicate what Capgemini was not obliged to do, and not what it would be liable for if work was done. As such, even if Mr Cabalag’s work on the Login Problem fell within the Scope Exclusions in the May 2020 SOW (which I do not find to be the case), this did not necessarily mean that Capgemini had not agreed to do this work and was not liable for the work done. This point becomes especially important because even if the work were to fall under the Scope Exclusions of the May 2020 SOW, Capgemini had billed for this work. Capgemini cannot have its cake and eat it too – it cannot seek remuneration for work that it had agreed to do, while suggesting that this same work remained excluded from the provisions of their contractual agreement with Razer.

79 To conclude, I am of the view that Mr Cabalag’s work could not have been covered only under the May 2020 SOW.

80 As I have found that the work which Mr Cabalag had performed on the Login Problem was covered by the scope of the April 2020 SOW, the question is whether the way in which the work was done had breached cl 3(ii) of the CSA. Razer submits that Capgemini has breached cll 3(ii)(a), (b) and (c) of the CSA.

81 Clause 5.1 of the April 2020 SOW expressly states that the SOW was entered into pursuant to the CSA. ¹¹⁶ Clause 3(ii) of the CSA reads: ¹¹⁷

82 Mr Douch accepted during cross-examination that if Mr Cabalag had done the Misconfiguration as WSL’s agent and employee, then he would have breached cll 3(ii)(a), (b) and (c). ¹¹⁸ I find that cl 3(ii)(a) has been breached as WSL, in failing to prevent the Misconfiguration, had not performed its services to an appropriate standard of proficiency, skill and quality. I also find that cl 3(ii)(c) has been breached as reasonable methods and due care had not been used to protect against harmful code – here, the misconfigured code in the Elasticsearch Configuration File – which hence impeded Razer’s systems from operating properly. I however decline to make any finding on whether cl 3(ii)(b) had been breached, as Mr Cabalag’s erroneous entry of the “#” symbol does not necessarily mean that he did not have the appropriate and adequate skill, qualifications and experience. It was obviously an oversight on the part of Mr Cabalag when he did not remove the “#” after he had resolved the Login Problem. But this does not mean that he did not possess the appropriate skill, qualifications and experience.

83 Razer also submits that Capgemini owed Razer separate and distinct obligations under the DPA – namely, under cl 7, to “take appropriate technical and organisational measures to ensure the confidentiality, integrity, availability and resilience of Supplier [referring to Razer] systems used for Processing Customer Data” and to “protect against the unlawful destruction, loss, alteration, unauthorised disclosure of or access to Personal Data transmitted, stored or otherwise Processed”. ¹¹⁹ It is undisputed that the personal data of Razer’s customers has been compromised. Capgemini however submits that cl 7 pertains to personal data in Capgemini’s own system, whereas personal data from Razer was stored in Razer’s own systems. ¹²⁰

84 Ms Patricia Liu acknowledged that that WSL had been engaged to put in place an e-commerce platform for Razer and hence the platform would sit on Razer’s IT infrastructure and not WSL’s infrastructure. She however also stated that it would be “stretching it” to say that this was Razer’s system and not WSL’s system as “supplier system” should be understood as a system put in place by the supplier, ie, WSL. ¹²¹

85 Indeed, given the context in which the DPA was signed, ie, to effect the Mulesoft integration, I do not think such an artificial delineation between Razer’s systems and Capgemini’s systems is tenable. This is not a situation where Capgemini’s scope of work entails storing data in its own systems for Razer – rather, its job is to set up systems through which data may be processed and viewed by Razer. Further, cl 7 when read in full describes the “Supplier Systems” as being that “used for Processing of Customer Data”. A plain reading of this phrase suggests that these systems are that which have been set up by WSL for Razer for the purposes of the Mulesoft integration.

86 Even if I am wrong on this, I note that cl 7 also imposes an obligation on Capgemini to protect against the unauthorised disclosure of personal data that is “transmitted, stored or otherwise Processed”. ¹²² I am of the view that even if the obligation under cl 7 pertaining to supplier systems refers only to systems sitting on WSL’s infrastructure, this portion of cl 7 is not limited in the same fashion and has clearly been breached.

87 Again, as I have found Capgemini to be in breach of cl 3(ii)(a) in its addressing of the Login Problem, it is not strictly necessary for me to deal with Razer’s case on Capgemini’s breach of an implied contractual duty of care. However, even if I am wrong in my finding of an express contractual breach, Capgemini still owes Razer an implied duty of care when troubleshooting the Login Problem and has breached this implied duty in its Misconfiguration of the Elasticsearch Configuration File.

88 Razer submits that Capgemini owed Razer an implied duty of care in respect of its troubleshooting of the Login Problem. ¹²³ Capgemini denies the presence of any such implied obligation since the express obligations providing for the applicable standards of work in cl 3(ii)(a) of the CSA would displace the existence of any implied obligations. ¹²⁴

89 Razer relies here on the case of Go Dante Yap v Bank Austria Creditanstalt AG [2011] 4 SLR 559 (“Go Dante Yap”), which states at [24] that:

90 This appears to me to be an implied term in law. To be clear, there are two main categories of implied contractual terms at common law – terms implied in fact, and terms implied in law: Ng Giap Hon v Westcomb Securities Pte Ltd and others [2009] 3 SLR(R) 518 (“Ng Giap Hon”) at [34]. Terms implied in fact refer to the possible implication of terms into a particular contract, while terms implied in law refer to where the decision of a court to imply a term in one case establishes a precedent for similar cases in future for all contracts of that particular type, unless it runs contrary to express words of the agreement: Ng Giap Hon at [35] and [38]; Jet Holding Ltd and others v Cooper Cameron (Singapore) Pte Ltd and another and other appeals [2006] 3 SLR(R) 769 at [90]–[92]; Chua Choon Cheng and others v Allgreen Properties Ltd and another appeal [2009] 3 SLR(R) 724 at [69].

91 In Go Dante Yap, the appellant opened a savings account and an investment account with the respondent bank. They entered into several agreements – namely, account opening and custodian agreements, an agreement giving the respondent the power and discretion to trade in securities on the appellant’s behalf using his accounts and investment authority instructions stating that the respondent was not authorised to make any investment or sell securities for the two accounts without the appellant’s instructions: at [8]. The court found that the respondent owed the appellant an implied contractual duty of care in carrying out his instructions under these agreements: at [25].

92 In Lister v Romford Ice and Cold Storage Co. Ltd. [1957] 1 AC 555, an appellant lorry driver, employed by the respondent company, drove his lorry to a slaughterhouse yard to collect waste. He was accompanied by his father. When backing his lorry up, the appellant knocked down and injured his father. The father successfully sued the respondent company for damages for his personal injuries. The respondents then commenced proceedings against the appellant for the damages awarded to his father. It was held that the appellant was under a contractual duty of care to his employers in the performance of his duty as a driver. As explained by Viscount Simonds LJ (at 572–573):

93 Having considered the above cases on implied contractual duty of care, I find that the agreement between Razer and Capgemini is similar in that Razer has enlisted the services of a party with a specific skill set and relied on Capgemini’s technical expertise for the Mulesoft integration. ¹²⁵ As Capgemini’s employees have been given unfettered access to Razer’s servers and the customer data stored on Razer’s servers, a lack of care in the exercise of such technical skills could very well put Razer in the unenviable position of having to deal with security breaches such as leaks of non-public data – as was the case here. I therefore find that Capgemini is indeed under an implied contractual duty to exercise reasonable care and skill in addressing the Login Problem.

94 Neither is this implied contractual duty at odds with the express obligations encapsulated in the CSA. Contrary to Capgemini’s submission, ¹²⁶ I do not think cl 3(ii)(a) would displace the existence of this implied duty. Rather, cl 3(ii)(a) would be aligned with and would reinforce the presence of such an implied duty by suggesting that Capgemini is held to a certain standard of skill and care. I further note that Razer has argued for the presence of an implied duty as an alternative to its submission that the express provision of cl 3(ii)(a) governs Capgemini’s work on the Login Problem. ¹²⁷ In the event that cl 3(ii)(a) does not apply to Capgemini’s assistance in the Login Problem, then it follows that cl 3(ii)(a) does not displace any implied duty in relation to the work done for the Login Problem.

95 I am hence of the view that Capgemini did owe Razer an implied contractual duty to exercise reasonable care, and in misconfiguring the Elasticsearch Configuration File.

96 Having arrived at the conclusion that Capgemini has breached its contractual agreement with Razer, it is not strictly necessary for me to consider Razer’s alternative claim in tort. For completeness, however, I will make a few comments on this claim. It is my view that Razer’s claim in negligence can be successfully made out against Capgemini.

97 To establish a claim in negligence, the plaintiff must establish that the defendant owes it a duty of care and that the defendant has breached this duty of care by acting or omitting to act below the required standard of care, that this breach has caused the plaintiff damage, and that the plaintiff’s losses arising from the defendant’s breach are not too remote and can be adequately proved and quantified: Spandeck Engineering (S) Pte Ltd v Defence Science & Technology Agency [2007] 4 SLR(R) 100 (“Spandeck”) at [21]. I will briefly address each element of the tort of negligence.

98 For claims arising out of negligence, a two-stage framework is applied to determine if a duty of care should be imposed on the defendant: Spandeck at [77] and [83]. The first stage entails a consideration of whether there is sufficient legal proximity between the plaintiff and defendant, while the second stage considers whether policy considerations would arise to negate this duty of care.

99 Before the claim can even take off, the court must be satisfied of the threshold question of factual foreseeability, ie, whether the defendant ought to have known that the claimant would suffer damage from his carelessness (Spandeck at [75]–[76]). Given the working relationship between Razer and Capgemini in Project Phoenix, I was satisfied that the threshold requirement was clearly crossed.

100 Moving on to the first stage of legal proximity, the focus rests on the closeness of the relationship between the parties (Spandeck at [77]) and includes physical, circumstantial and causal proximity (at [81]). The twin criteria of voluntary assumption of responsibility and reliance are essential factors in meeting the test of proximity (at [81]). As I have found that Capgemini owes Razer an implied contractual duty of skill and care, this would suffice to create legal proximity for a duty of care in tort to arise (Go Dante Yap at [20] and [34]). I am also satisfied that there are no policy reasons militating against the imposition of this duty of care.

101 Generally, the standard of care required to fulfil one’s duty of care is the general objective standard of a reasonable person using ordinary care and skill (Greenway Environmental Waste Management Pte. Ltd. v Cramoil Singapore Pte Ltd [2021] SGHC 203), although factors such as industry standards and normal practice can be taken into account (Jurong Primewide Pte Ltd v Moh Seng Cranes Pte Ltd and others [2014] 2 SLR 360 at [43]).

102 Capgemini was engaged by Razer for the purposes of the Mulesoft integration, and Mr Cabalag was deployed in his capacity as Capgemini’s technical architect. Indisputably, as an information technology consultant, Capgemini would have been expected to provide technical expertise and solutions to technical problems, and this is borne out in the evidence of both sides’ witnesses. For instance, it was acknowledged by Mr Douch that Mr Cabalag had the technical skill and know-how to address the Login Problem. ¹²⁸ Razer’s reliance on Capgemini for technical solutions is also evinced from Ms Liu’s evidence that Razer did not have its own homegrown IT solutions and systems, ¹²⁹ and Mr Pradeep’s evidence that even he, as the Razer representative to whom Mr Cabalag reported, did not have experience or expertise with the ELK stack ¹³⁰ and had to reach out to Mr Cabalag for help on the Login Problem as he was the one who suggested and set up the ELK system. ¹³¹

103 Given the above, my view is that a reasonable information technology consultancy company in Capgemini’s position would be expected to satisfactorily address matters such as the Login Problem without compromising Razer’s security and private data. Capgemini, in misconfiguring the Elasticsearch Configuration File, had clearly fallen below the standard that would be expected of an information technology consultancy exercising ordinary care and skill.

104 In effecting the Misconfiguration through its breach of its duty of care, I am satisfied that Capgemini has caused damage to Razer. The damage is not too remote, having resulted directly from the publicising of the Data Leak by Mr Diachenko. Capgemini submits that Razer had failed to take reasonable steps in response to Mr Diachenko’s August Communication – specifically through Ms Tiong’s failure to act in accordance with Razer’s own standard protocol and escalate the issue to Razer’s executive management or to resolve the Security Incident. ¹³²

105 It is also to be noted that while Capgemini avers that the Security Incident had been made known to Razer in or around August 2020, ¹³³ Razer avers that its management team in Singapore only knew of the incident on or about 9 September 2020, and that Mr Diachenko had reached out to an entity separate and distinct from Razer regarding the Security Incident in or around August 2020. ¹³⁴

106 However, it appears that even if Razer had done so, the publicising of the Data Leak and the damage to Razer flowing from it would not have been averted. Mr Goh Soon Liong (“Mr Goh”), Vice-President of Razer’s Software Business Unit, expressed his view that even if Ms Tiong had acted in line with protocol, Mr Diachenko would still have gone public and disclosed the Security Incident. ¹³⁵ He also explained the profile and standard practices of ethical hackers such as Mr Diachenko: ¹³⁶

107 Capgemini has not given any evidence to suggest otherwise. On the face of Mr Goh’s evidence, it appears more likely than not that Mr Diachenko would have publicised the Security Incident regardless of any action Razer had taken in response to his August Communication.

108 While I am satisfied that Capgemini’s negligence has caused damage to Razer, the quantification of the damage and/or loss incurred is a contested issue in this suit. I will address it in full below at [124]–[155].

109 As I have found that Mr Cabalag’s work fell under the purview of the April 2020 SOW, and hence that Capgemini is liable both in contract and in tort for the work done, it is not necessary for me to consider Razer’s alternative submissions that Capgemini is vicariously liable for Mr Cabalag’s actions, ¹³⁷ or Capgemini’s submission that Mr Cabalag was an agent of Razer under the May 2020 SOW. ¹³⁸

110 Capgemini pleads that if it is held to be negligent to Razer, any damage suffered by Razer must take into account Razer’s contributory negligence in its delay in responding to Mr Diachenko’s August Communication. ¹³⁹ Razer had failed to properly manage its employees in relation to the communication, including implementing operating procedures relating to the escalation of communications and ensuring compliance with these procedures, and promptly responding to the communication to rectify the incident. ¹⁴⁰

111 However, Capgemini does not make submissions on contributory negligence but focuses instead of the defences of novus actus interveniens and on mitigation of damages. I will, for the sake of thoroughness, address the pleaded point on contributory negligence before dealing with the submissions made regarding novus actus interveniens and mitigation.

112 Per s 3(1) of the Contributory Negligence and Personal Injuries Act (Cap 54, 2002 Rev Ed), damages recoverable by a claimant shall be reduced to such extent as the court thinks just and equitable having regard to the claimant’s share in the responsibility for the damage. The key considerations guiding the court’s discretion to apportion liability between a claimant and a defendant are the relative causative potency of the parties’ conduct, and the parties’ relative moral blameworthiness (Rohini d/o Balasubramaniam v HSR International Realtors Pte Ltd [2018] 2 SLR 463 (at [54]), citing Asnah bte Ab Rahman v Li Jianlin [2016] 2 SLR 944 at [118]).

113 It appears to me that it is the Misconfiguration of the Elasticsearch Configuration File which is of dominant causative potency. Razer’s evidence is that Mr Diachenko would have released information on the Data Leak regardless of what Razer had done in response to the August Communication and Capgemini has not provided any evidence to suggest that the reverse is true (see above at [104]–[107]).

114 Capgemini merely points to the wording of a warning letter ¹⁴¹ issued to Ms Tiong Lee Lan. In the letter, it was stated that “the extent of the issue would have been significantly mitigated” if Ms Tiong had carried out the appropriate incident response or evaluated the veracity of Mr Diachenko’s initial email. However, I did not think the wording of an internal company reprimand sheds any light on whether Razer had caused the damage or that it would have suffered less damages had it acted timeously.

115 Given the foregoing reasons, I do not find Razer to be contributorily negligent for the damage and/or losses caused by the Misconfiguration.

116 In closing submissions, Capgemini focuses on how Razer’s failure to respond adequately to the August 2020 Warning and rectify the incident at the earliest opportunity constituted a novus actus intervenions. ¹⁴² Razer has pointed out that this was not Capgemini’s pleaded case. ¹⁴³

117 In fact, Capgemini had requested on 4 July 2022 to amend its Defence to include the defence of novus actus interveniens, and I had declined to allow amendments to the Defence given the lateness of this request. ¹⁴⁴
In its reply submissions, Capgemini attempts to make the argument that it had pleaded the relevant facts to support the defence of novus actus interveniens, by pointing to how it had denied in its Defence that it was responsible for the incident. ¹⁴⁵ Capgemini also suggests that it was sufficient that it had pleaded that Razer “[failed] to take reasonable steps in response to the August Communication”, as it was required to plead material facts but not legal arguments. ¹⁴⁶

118 I do not accept Capgemini’s reasoning. It is trite law that parties are bound by their pleadings: V Nithia (co-administratrix of the estate of Ponnusamy Sivapakiam, deceased) v Buthmanaban s/o Vaithilingam and another [2015] 5 SLR 1422 (“V Nithia”) at [38].The court would permit an unpleaded point to be raised only in limited circumstances, where no prejudice is caused to the other party or where it would be clearly unjust for the court not to do so: at [40]. Parties should at least disclose the material facts that would support their claim, such that their opponents are not taken by surprise by their case: at [42]–[44].

119 A mere denial of liability is not sufficient in this case, especially since the denial in question pertains to the position that Capgemini had not done anything to cause the Security Incident at all – not that it had done so but that Razer’s actions (or lack thereof) constituted a supervening cause. Neither was it sufficient for Capgemini to plead that Razer had failed to take reasonable steps in response to the August Communication, as it had pleaded that the taking of such steps would have “significantly reduced the alleged loss and damage incurred” ¹⁴⁷ – which is rather different from breaking the chain of causation.

120 In any event, as I have found above (at [104]–[107]), there is insufficient evidence to suggest that if Razer had responded to the August Communication, Mr Diachenko would not have publicised the data breach incident.

121 Capgemini also submits that Razer was entitled to no damages or nominal damages as it had not taken all reasonable steps to mitigate its losses (see above at [104]). ¹⁴⁸ As I have found that Mr Diachenko would more likely than not have publicised the Data Leak regardless of how Razer had escalated, managed or responded to the August Communication, Capgemini’s defence of mitigation fails.

122 I hence find that Mr Cabalag’s assistance on the Login Problem was covered under the April 2020 SOW and was performed in his capacity as an employee of Capgemini. Capgemini has breached its obligations under the CSA and the DPA, and in the alternative, has been negligent in its response to the Login Problem. I now turn to the issue of the reliefs to be granted.

123 Razer seeks the following reliefs:

(a) Damages.

(b) A declaration that Razer be fully indemnified by Capgemini for all damages, losses and expenses incurred and which it may incur as a result of the Security Incident.

(c) Interest. ¹⁴⁹

124 Mr Tan Chong Neng (“Mr Tan”), the Chief Financial Officer of Razer’s parent company, Razer Inc, gave evidence on the estimated loss and damages arising from the Security Incident. ¹⁵⁰ Both parties also adduced expert evidence to support their positions on the damages to be granted. Razer called Ms Victoria Anne Wall (“Ms Wall”) to assess the losses and damages suffered by Razer. Capgemini in turn called Mr Eddy Lee (“Mr Lee”) to provide an opinion on the calculations and quantifications relied upon by Razer.

125 Razer seeks the following damages: ¹⁵¹

(a) Loss of profits arising from the decrease in sales revenue of Razer.com in respect of its video game systems and gaming peripherals, quantified at USD6,136,112.

(b) Loss of profits arising from rejection of a digital bank license application, fixed at a nominal sum of S$50,000.

(c) Time and expenses expended by the management and staff, fixed at a nominal sum of S$50,000.

(d) Cost of Razer’s engagement of an information technology forensic expert, Blackpanda Pte Ltd (“Blackpanda”), to conduct forensic investigations, quantified as USD60,237.00.

(e) Cost of Razer’s engagement of law firm Norton Rose Fulbright (“NRF”) to advise on Razer’s data protection and reporting obligations and to represent Razer in regulatory investigations arising out of the Security Incident quantified at USD320,389.81.

(f) Loss and damage arising from compensation paid by Razer to Mr Diachenko under Razer’s bug bounty programme, quantified at USD2,000.

126 Razer also seeks to recover costs paid and/or payable to its solicitors and damages expert in this present suit. ¹⁵²

127 Ms Wall’s calculations were that the claim for the loss of profits from the decrease of sales revenue for Razer.com would likely stand at USD6,136,112, being:

(a) USD3,159,224 of loss in respect of Razer.com’s gaming systems.

(b) USD2,976,888 of loss in respect of Razer.com’s non-gaming systems. ¹⁵³

128 The 2020 profit margin, which was relied on to produce the above calculated loss, was calculated at 20.6% for video game systems and 37.6% for gaming peripherals. ¹⁵⁴ Ms Wall’s calculations were premised on a few assumptions:

(a) The loss period (the “Assumed Loss Period”) was set as between 10 September 2020 – the date of the Linkedin article which made the security breach public – to 31 December 2020 – as Razer’s revenue had reached the amount which it should have achieved but for the Security Incident (the “But-for Revenue”) by February 2021. ¹⁵⁵

(b) The But-for Revenue was calculated based on the actual revenue achieved in the Assumed Loss Period, adjusted to take the results of Razer’s increased 2020 revenue into account. This was done instead of simply adopting Razer’s contemporaneous forecasts, as Ms Wall considered that these forecasts would often be more ambitious than the actual results and would not have taken into account the large increase in revenues experienced by the PC gaming industry as a result of the Covid-19 pandemic. ¹⁵⁶

(c) 1 April 2020 was considered an appropriate estimate of when Covid-19 began to positively impact Razer.com sales. The But-for Revenue was calculated using the ratio of the revenue for April 2020 to August 2020 to the same period in 2019. ¹⁵⁷

(d) The costs of the product itself, the packaging and shipping costs and the payment charges were taken into account when calculating the lost profits. However, the excess and obsolescence write offs related to prior years’ products were removed as they would have been incurred at the same level regardless of whether Razer made additional sales. The depreciation costs of tooling machinery were also removed as it would not increase with additional sales. ¹⁵⁸

(e) The average profit margin over the whole of 2020 was used to calculate the appropriate profit margin, as using monthly profit margin figures would risk distorting the results for any month. ¹⁵⁹

129 On a preliminary note, Mr Lee does not dispute the mathematical accuracy of Ms Wall’s calculations of loss of profits. ¹⁶⁰ Rather, he provides a critique of her approach to calculation and the adopted assumptions behind these calculations, ¹⁶¹ but notes that he does not have sufficient information to provide his own assessment of the losses sustained by Razer. ¹⁶²

130 Mr Lee opined that the amounts claimed by Razer were insufficiently supported and lacked a consideration of:

(a) Other factors which would affect sales, such as product launches and seasonality.

(b) Evidence of the accuracy of forecast targets prepared in the previous financial year.

(c) Evidence to show that the forecast targets were still applicable in light of the Covid-19 pandemic.

(d) Information on whether the lost online sales were mitigated by sales at physical stores, online avenues or other distribution channel.

(e) Overly high forecast targets for sales of gaming peripherals.

(f) Whether the potentiality of delays in product launches had been the cause of the claimed reduction in sales.

(g) Whether the gross profit margins adopted in Razer’s claim are appropriate. ¹⁶³

131 Mr Lee took issue with Ms Wall’s use of the time period of September 2020 to 31 December 2020 as the period during which losses were said to have happened. His opinion was that only 246 of Razer’s customers had sent emails with their concerns about the Security Incident. ¹⁶⁴ Further, for these 246 customers, Mr Lee suggests that there is no indication that they would stop buying products from Razer, and that the effect of the Security Incident appears to be short-lived and mostly resolved by September 2020. ¹⁶⁵ Razer’s position is that this criticism was a non-starter as Mr Lee was not able to draw conclusions on any customers outside of 246 customers. ¹⁶⁶ Capgemini however submits that the burden of proof remains on Razer, and that Mr Lee’s critique demonstrates that Razer has not discharged its burden of proof as its calculations of loss can only be premised on the 246 customers who were shown to actually have been affected. ¹⁶⁷

132 To me, the evidence of 246 customer queries is sufficient to prove, on a balance of probabilities, that the Security Incident had impacted the willingness of customers to purchase products from Razer.com. I agree that the burden lies on Razer to prove the losses for which it is seeking damages; I however do not agree that the only way for Razer to discharge its burden of proof is to provide a precise quantification of how many customers had declined to purchase products from Razer.com. Moreover, the act of writing to Razer is not a direct indicator of a customer’s decision to not buy products from Razer.com. In fact, when questioned on the stand, Mr Lee himself accepted the possibility that disgruntled customers may not have written to Razer, but still chosen not to buy products from Razer.com. ¹⁶⁸

133 Further, the fact that the Data Leak itself was resolved by September 2020 is irrelevant in that there is insufficient evidence to suggest that customer opinions would go back to how they were before the Security Incident once it was resolved. I hence saw no reason to displace Ms Wall’s opinion that the relevant loss period was September 2020 to 31 December 2020.

134 Mr Lee also suggested that Ms Wall had applied too high an uplift to take into account the effect that COVID-19 would have on Razer’s But-for Revenue. Essentially, when calculating the But-for Revenue, Ms Wall had applied an uplift to the revenue for the Assumed Loss Period to reflect the increased revenue Razer.com would have experienced due to the Covid-19 pandemic. She estimated that 1 April 2020 was when the COVID-19 pandemic first began impacting Razer.com’s sales, and hence derived an uplift percentage by comparing the results from April 2020 to August 2020 (ie, before the Security Incident allegedly affected sales), to the data for the same period in 2020. ¹⁶⁹ This uplift percentage was then applied to the actual 2019 revenues for the period of the damages calculation, to give the But-for Revenue for the Assumed Loss Period in 2020. ¹⁷⁰

135 Mr Lee, however, opines that the positive effect of COVID-19 on sales was likely waning in the Assumed Loss Period. ¹⁷¹ Further, Mr Lee has taken the ratio of Razer.com’s sales revenues (for both peripherals and systems) in the third quarter of 2019 to that of the third quarter of 2020, and compared that with the ratio of Razer.com sales revenues in the fourth quarter of 2019 to that of 2020. ¹⁷² In doing so, he found that the fourth-quarter ratio was lower than the third-quarter ratio, thereby suggesting that the positive effect of COVID-19 on sales revenue would have waned in the fourth quarter of 2020. To further substantiate his point, he also notes that this downward trend is also mirrored in other distribution channels of Razer. ¹⁷³

136  Razer submits that insofar as Mr Lee had not taken a position on what an appropriate uplift would be instead, and as Capgemini had not sought any of the information which Mr Lee stated that he would have needed to calculate his preferred uplift percentage, Mr Lee’s opinion should be given little to no weight. ¹⁷⁴ Capgemini reiterates Mr Lee’s critique of Ms Wall’s uplift percentage, ¹⁷⁵ and submits that Mr Lee could not have quantified his preferred uplift percentage as information such as the online sales of third parties was required for this purpose. Capgemini also submits that in not providing such required information, an adverse inference should be drawn against Razer that this information would have been detrimental to Razer’s case, and that Razer has not discharged its burden of proof. ¹⁷⁶

137 I begin by saying that it is not strictly necessary for Mr Lee to provide his own opinion of what an appropriate uplift might be, even if doing so might have been more beneficial towards Capgemini’s case or provided greater assistance to this Court. However, I did not see any basis on which an adverse inference should be granted against Razer for not disclosing information that its expert witness did not require for her calculations, and which Capgemini had not applied for disclosure thereof. The drawing of adverse inferences under s 116(g) Evidence Act (Cap 97, 1997 Rev Ed) depends on the evidence adduced and the circumstances of each case, and should not be used as a mechanism to shore up deficiencies in one’s own case which on its own is unable to meet up the requisite burden of proof: Tribune Investment Trust Inc v Soosan Trading Co Ltd [2000] 2 SLR(R) 407 at [50]. Where Capgemini is unable to justify its opposition to the uplift calculated by Ms Wall, it cannot rely on the regime of casting adverse inferences to compensate for the gaps in its allegation that Ms Wall’s uplift is too high.

138 In any event, with all due respect to Mr Lee, I do not think it makes sense to compare Razer.com’s sales revenue in the fourth quarters of 2019 and 2020 to its sales revenue in the third quarters of 2019 and 2020, and thereby to conclude that the uplift effect of COVID-19 on sales revenue has declined. ¹⁷⁷ After all, the fourth quarter of 2020 is when the Assumed Loss Period runs, and the actual sales revenue then would already be affected by the impact of the Security Incident. Further, when Ms Wall suggested that given the similarity between the sales revenues in the second and fourth quarter of 2020, an alternative means of calculation would be to use the reference period of April to June 2020 to calculate the uplift percentage instead, ¹⁷⁸ Mr Lee disagreed with this alternative approach as well. He explained that in any case it was inappropriate to apply an uplift (be it derived from the second or third quarter of 2020) and to apply it to the fourth quarter as “there is a dip in quarter 4, and that is the period that the losses are assessed”. ¹⁷⁹ His reasoning is puzzling – comparisons to the fourth quarter of 2022 were used by him to justify a lower uplift, and yet he is against the application of any uplifts to the fourth quarter, no matter which reference period is used to derive the uplift percentage. I hence do not see how extra information on matters such as third-party sales would shed light on a more accurate measure of the COVID-19 effect on Razer.com’s sales revenue than the measures proffered by Ms Wall. I also find that Mr Lee’s opinion that the uplift should be lower is not justified by the evidence before me.

139 Capgemini highlights that the products launched in the last quarters of 2019 and 2020 differ greatly in price and nature, and hence that Ms Wall’s uplift percentage is flawed in that it is premised on the assumption that there were identical product launches with identical effects on sales. ¹⁸⁰ Razer submits that there is no discernible trend relating to the presence or absence of new product launches in the two years. ¹⁸¹ Having considered the evidence before me, I am of the view that there is insufficient evidence to suggest a predictable causal relationship between the product launches of 2019 and 2020 and revenue trends. I hence do not find that Ms Wall had erred in her calculations in treating product launches as a neutral factor.

140 Mr Lee also opined that Ms Wall ought to have taken into account Razer’s production capacity and variable costs. Razer submits that these criticisms are non-starters. Capgemini had not adduced any evidence or cross-examined any individual from Razer either on Razer’s production capacity or on whether Mr Tan had understated Razer’s variable costs. ¹⁸² For the avoidance of doubt, it is not Capgemini’s position that Razer in fact lacked production capacity, but that Ms Wall should have taken steps to verify what the production capacity and variable costs might be. ¹⁸³

141  I note that Mr Lee draws no conclusions on whether Razer lacked production capacity or whether there were in fact any variable costs that had not been properly accounted for in Ms Wall’s calculation. It is not possible for me to find fault with Ms Wall’s approach based merely on what-ifs. In all fairness to Mr Lee, it would not have been possible for him to venture beyond the realm of speculation simply because he lacked evidence on Razer’s production capacity and variable costs. That being said, Capgemini had ample opportunity to request information on these points, or to question Mr Tan when he was on the stand. This having not been done, it was reasonable of Ms Wall to have relied on Mr Tan’s evidence that Razer had sufficient production capacity, and for Ms Wall to not have included more variable factors into her calculations. In other words, on the evidence available, I find it more likely than not that Ms Wall’s approach in this regard was correct.

142 Mr Lee takes issue with the use of the average profit margin for the whole of 2020 rather than just the average margin during the Assumed Loss period of September to December 2020, as using only the Assumed Loss period would be closer to the actual amounts lost. ¹⁸⁴ While Ms Wall acknowledged that she was not averse to relying only on the Assumed Loss period to derive the profit margin, she highlighted that there were “undue fluctuations” such as large sales returns in December, which would be negated or balanced out by a longer period of calculation. ¹⁸⁵ Mr Lee noted that there were also large sales returns in other months such as May and April, ¹⁸⁶ but I do not find this to be a compelling reason why a shorter period of time should be used instead. On the contrary, the longer the period of time, the likelier it is that these fluctuations (the existence of which neither party has denied) would be balanced out.

143 Mr Lee has also suggested that Razer’s losses could have been mitigated if customers had chosen to purchase Razer’s products from other sales channels. ¹⁸⁷ However, he also acknowledged that “there is no information that has been disclosed for [him] to consider this issue”. ¹⁸⁸ In response, Ms Wall noted that it would not be possible to tell, just from looking at the revenue or sales figures, whether there had been any diversion of the sales revenues to other Razer channels – it was just as possible that “people chose not to use Razer at all or gone somewhere else or they could have gone to Razer or gone to competitors”. ¹⁸⁹

144 Razer seeks to rely on Mr Tan’s evidence that Razer.com caters to a specific group of gamers who value Razer.com’s customer service and warranty, and who would hence not buy from other e-commerce platforms or physical stalls. ¹⁹⁰ Capgemini in turn highlights that there is an absence of evidence to substantiate Mr Tan’s point that Razer’s customers would have preferred to switch to another brand rather than purchase Razer’s products via a different channel. ¹⁹¹ In my view, given the lack of evidence to either support or contradict Mr Tan’s evidence, it would be unsafe for this Court to conclude that any mitigation had occurred. I hence considered it reasonable that Ms Wall had not included considerations of any such mitigation in her calculation approach.

145 This head of loss concerned Razer’s application for a digital bank licence from the Monetary Authority of Singapore (“MAS”), following the MAS’s announcement in June 2019 that it was issuing up to five new digital bank licences. Razer’s representatives were questioned on the adverse news reports relating to the Data Leak and Razer did not receive the bank licence.

146 Ms Wall stated that as she was not aware of any contemporaneous forecasts of the profits which Razer expected to make from the banking licence, ¹⁹² and hence reviewed the potential perceived value of the banking licence by reference to Razer’s share price. ¹⁹³ Specifically, she reviewed Razer Inc’s share price and overall market capitalisation movement on two occasions: firstly the increase in share price when Razer announced it would bid for the licence, and secondly the decrease in share price when it was announced that Razer had not won the bid. ¹⁹⁴ While she considered Razer Inc’s overall market value around these announcements to be broadly indicative of the value placed by the market on the banking licence, she recognised that estimating the exact impact of the announcements is speculative, since the exact time period during which the market reacted to the two announcements and the impact of any other events or announcements on Razer’s share price were unknown. ¹⁹⁵

147 Capgemini submits that the alleged losses resulting from the rejection of the digital bank licence are too remote and/or speculative. ¹⁹⁶ Razer attempts to buttress its submission that the Data Leak was a critical and material factor in its failure to obtain the bank licence, by its reasoning that if a digital bank cannot ensure that its customer data is protected, there will be doubts as to whether it can uphold the integrity of the entire banking system. ¹⁹⁷ Given the dearth of evidence to suggest a causal link between the Security Incident and the rejection of its licence application, Razer’s line of reasoning appears to me to be exactly the kind of unsubstantiated speculation that Capgemini takes issue with. Ms Wall has been candid in acknowledging the speculative nature of estimating losses flowing from the rejection of the licence application, and Razer itself acknowledges the difficulty of quantifying this claim. ¹⁹⁸ I hence reject Razer’s claim for nominal damages for the rejection of its licence application.

148 Razer seeks S$50,000 in nominal damages as it had to divert management and staff time from ordinary day-to-day jobs to respond to the Data Leak incident. ¹⁹⁹ Mr Tan’s evidence was that an estimated 2,500 man hours were spent but that time sheets were not kept by Razer as its foremost consideration was to resolve the issue, and as Razer’s staff and management were not required to keep timesheets in their day-to-day work. ²⁰⁰ Capgemini submits that any alleged losses for this head of claim are arbitrary and unsubstantiated by any supporting documents. ²⁰¹

149 I agree with Capgemini on this point. While Mr Tan’s explanation as to why timesheets were not kept may be plausible, no evidence has been put before this court as to who was activated to deal with the Security Incident. Neither has any supporting documentation been provided as to what other work they had been diverted from carrying out – or whether responding to contingencies such as this Security Incident was even outside of their scope of work in the first place. While Razer has, in recognition of how it lacks documentation of the man-hours expended on resolving the Security Incident, sought only nominal damages, ²⁰² I do not think that there was sufficient evidence to warrant this.

150 Razer seeks the sum of USD320,389.81 incurred in engaging NRF to advise and act for Razer in dealing with regulators in the aftermath of the Security Incident. ²⁰³

151 Capgemini firstly argues that the losses were self-induced as it would have avoided inquiry and investigation by data protection regulators in Singapore, Australia and Malaysia had it responded timeously to Mr Diachenko. ²⁰⁴ I accept, however, Razer’s argument that even if Razer had responded to Mr Diachenko, the fact remains that Razer’s customer data had been exposed since June 2020, before Mr Diachenko’s communication – and this would still have been the subject of inquiry and investigation. ²⁰⁵ Further, having found that Mr Diachenko would have publicised the Security Incident regardless (see above at [104]–[107]), I am of the view that it makes no difference whether Razer had responded to Mr Diachenko timeously or not.

152 Second, Capgemini argues that Razer has not established that it was mandatory to report the Data Leak to authorities in Singapore, Germany, Australia and Malaysia. Further, Razer could not supply a reason why it did not report the Data Leak to regulators in the USA. ²⁰⁶ In my view, in light of the severity of a leak of customers’ non-public data, it was reasonable for Razer to have sought professional advice on the regulatory implications of the Security Incident – even if it was not mandatory in a particular country to report such data breaches.

153 I hence award Razer damages for its engagement of NRF to advise and act for it in responding to data protection regulators.

154 Razer seeks USD2,000 for the payment to Mr Diachenko under the bug bounty programme. ²⁰⁷ Capgemini does not dispute this sum in the event that it is found liable to Razer. ²⁰⁸ As such, I find in favour of Razer on this head of loss.

155 Razer seeks USD60,237.00, which constitutes the fees and disbursements paid to its forensic expert, Blackpanda Pte Ltd, in respect of forensic investigations conducted in respect of the Security Incident. ²⁰⁹ As Capgemini does not dispute this sum in the event that it is found liable to Razer, ²¹⁰ I find Capgemini liable for the sum of USD60,237.00 to Razer.

156 Razer seeks a declaration that cl 12 of the CSA and cl 12 of the DPA w ould apply.

157 I reproduce the relevant portions of cl 12 of the CSA:

158 I also reproduce cl 12 of the DPA:

159 As I have found Capgemini liable in contract and in negligence for damages caused to Razer, there is no purpose for this declaratory relief.

160 For the above reasons, I find that Capgemini has breached its obligations under the CSA and the DPA, and in the alternative, has been negligent in its response to the Login Problem. I order Capgemini to pay Razer the following sums in damages:

(a) USD6,136,112 for Razer’s loss of profits for the sale of video game systems and gaming peripherals from Razer.com.

(b) USD320,389.81 for the costs incurred in engaging NRF to advise and act for Razer.

(c) USD2,000 for the payment made to Mr Diachenko under the bug bounty programme.

(d) USD60,237.00 for fees and disbursements paid to Blackpanda Pte Ltd.

161 I will hear parties on costs.