DBN Guideline

When must a personal data breach be notified to the regulator and affected data subjects?

A data controller must notify a personal data breach to both the Commissioner andaffected data subjects if it causes or is likely to cause “significant harm”, which includes a risk for any of the following:

• physical harm, financial loss, a negative effect on credit records, or damage to or loss of property;
• misuse of personal data for illegal purposes;
• compromise of sensitive personal data;
• combination of personal data with other personal information that could potentially enable identity fraud; or
• (for the purpose of notification to the Commissioner only) a breach of “significant scale”, i.e. involving more than 1,000 affected data subjects.

What is the timeframe to make data breach notifications?

The timeframe for notifications is as follows:

• Notification to the Commissioner: as soon as practicable and within 72 hours from the occurrence of the breach. If notificationfails to be made to the Commissioner within 72 hours, a written notice detailing the reasons for the delay and providing supporting evidence must be submitted; and
• Notification to affected data subjects: without unnecessary delay and within seven days of notifying the Commissioner.

What are the other key obligations related to personal data breaches?

A data controller should:

• DPA:  contractually obligate its data processor to promptly notify it of a data breach and to provide it with all reasonable and necessary assistance to meet its data breach notification obligations;
• Management and response plans: put in place adequate data breach management and response plans;
• Training: conduct periodic training as well as awareness and simulation exercises to prepare its employees for responding to personal data breaches;
• Breach assessment and containment: act promptly as soon as it becomes aware of any personal data breach to assess, contain, and reduce the potential impact of the data breach, including taking certain containment actions (such as isolating compromised systems) and identifying certain details about the data breach in its investigation; and
• Record-keeping: maintain a register of the personal data breach for at least two years to document the prescribed information about the data breach.

DPO Guideline

Who are required to appoint DPOs?

An organisation, in the role of either a data controller or a data processor, is required to appoint a DPO if its processing of personal data involves:

• personal data of more than 20,000 data subjects;
• sensitive personal data including financial information of more than 10,000 data subjects; or
• activities that require “regular and systematic monitoring” of personal data.

Who can be appointed as DPOs?

DPOs may be appointed from among existing employees or through outsourcing services based on a service contract. They must:

• Expertise: demonstrate a sound level of prescribed skills, qualities and expertise;
• Language: be proficient in both Malay and English languages; and
• Residency: be either resident in Malaysia or easily contactable via any means.

What are the other key obligations related to DPO appointments?

A data controller required to appoint a DPO should:

• Notification: notify the Commissioner of the appointed DPO and their business contact information within 21 days of the DPO appointment;
• Publication: publish the business contact information of its DPO through:

• its website and other official media;
• its personal data protection notices; or
• its security policies and guidelines; and
• Record-keeping: maintain records of the appointed DPO to demonstrate compliance.

A data processor required to appoint a DPO should comply with the publication and record-keeping obligations above in relation to its DPO.

Next Steps The new guidelines represent a significant step in the implementation of the newly introduced data breach notification and DPO appointment requirements. All organisations subject to the PDPA, whether data controllers or processors, should carefully review the guidelines and take steps to ensure compliance by 1 June 2025. This includes updating relevant internal policies (such as data breach response plans and record-keeping and training policies) and contracts with data processors to align with the guidelines. Additionally, organisations should assess whether a DPO appointment is necessary and, if so, be prepared to complete the appointment and notification processes and update their privacy notices, websites and other media to include DPO information.

Data Breach Risk Assessment

Under the PDPA, data controllers are required to notify the office of PDPC of a data breach incident without delay and within 72 hours of becoming aware of the breach, unless the breach has no risk on individuals’ rights and freedoms.

The PDPC clarified that data controllers should assess the risk to individuals’ rights and freedoms by considering the factors outlined in Section 12 of the Notification of the Personal Data Protection Committee on Criteria and Procedures for Personal Data Breach Notification B.E. 2565 (2022) (“Notification“).

These factors include:

1. The nature and category of the personal data breach.
2. The type and volume of affected personal data, and the status of the affected data subjects (e.g., minors, disabled persons, vulnerable individuals).
3. The severity of the impact and potential damage to the affected data subjects, including the effectiveness of the preventive or remedial measures.
4. The broad-ranging effects on the data controller’s business or public due to the breach.
5. The nature of the relevant data storage system and associated security measures, including organizational, technical, and physical measures.
6. The legal status of the data controller.

If data controllers determine that the breach poses no risk to individuals’ rights and freedoms by considering these factors, they are not obligated to notify the PDPC. However, the PDPC advised that data controllers retain all information, documents, and records related to the risk assessment as evidence in case of future complaints, regulatory inquiries, or inspections.

Starting the 72-Hour Period

The PDPC advised that the 72-hour notification period begins when the data controller reasonably believes a breach has occurred or is likely to occur, based on a preliminary assessment and verification as specified in Section 5 of the Notification.

According to Section 5 of the Notification, upon data controllers being informed of a data breach incident, data controllers must first verify the credibility of the information, promptly investigate the relevant facts, and review the security measures in place (for both themselves and their data processors), including investigate the data controllers’ and their processors’ personnels, to determine whether there are reasonable grounds to believe a breach has occurred.

The PDPC further clarified that the precise commencement of this 72-hour period must be evaluated individually for each case. In certain situations, breaches may be immediately evident, such as when personal data is mistakenly sent to an incorrect email recipient. Conversely, other cases may necessitate additional time to verify the breach, such as when investigating a reported data leak resulting from a cyberattack. Data controllers should exercise its judgment to ascertain when there are sufficient grounds to suspect a breach has occurred.

Phased Notification and Late Notification of Data Breaches

The PDPC explained that in cases where a personal data breach poses a risk to the rights and freedoms of individuals, data controllers may consider notifying the PDPC in phases. Initially, data controllers should report the breach as soon as possible, providing preliminary information. Additional details can be submitted later once further investigation has been conducted and more information is available.

If a data controller is unable to notify the PDPC within the 72-hour timeframe, they must do so as soon as possible, but no later than 15 days from becoming aware of the breach. The data controller must provide a valid explanation and relevant details to the PDPC, demonstrating that the delay was due to unavoidable circumstances.

This approach provide flexibility and allows data controllers to manage the breaches effectively while ensuring compliance with the legal requirements.

Conclusion

The clarifications provided by the PDPC on data breach notification requirements are essential for organizations striving to comply with the PDPA. Data controllers can now make informed decisions about whether to report a data breach using the outlined criteria for assessing the risk to individuals’ rights and freedoms. The emphasis on timely notification given by the PDPC further allows data controllers to manage data breaches effectively. Additionally, the guidance on phased notifications and allowances for delayed reporting provides flexibility for data controllers in dealing with breaches, ensuring they can meet legal requirements. By adhering to these clarifications, business operations can protect individuals’ rights and freedoms while maintaining compliance with the PDPA.

Anyone with a passing interest in Australian privacy laws will no doubt have heard about the Optus data breach. The incident, which was made public in late September 2022, is thought to have affected around 9 million individuals (almost 40% of the Australian population), with identity documents relating to approximately 2.22 million Australians being made available on the dark web. The news was swiftly followed up with an announcement from Medibank, Australia’s largest private health insurer, of a breach affecting all of its 3.9 million customers.

As part of the Australian Government’s response to the public outcry generated by these breaches, a change to the Privacy Act 1988 (Cth) has been introduced into the Australian Parliament.  If passed, this will increase the maximum civil penalties payable under the Act from the current AUD 2.22 million to the greater of:

• AUD 50 million;
• three times the value of the benefit resulting from the breach; or
• 30% of the adjusted turnover of the entity in the 12 months prior to the breach.

The draft Bill (titled the Privacy Legislation Amendment (Enforcement and Other Measures) Bill 2022) also seeks to strengthen the Office of the Australian Information Commissioner’s powers to request information in order to assess actual or suspected data breaches and changes the extraterritorial reach of the Australian privacy regime. Organisations will no longer be required to collect or hold personal information within Australia in order for the Privacy Act 1988 (Cth) to apply. They must however still be carrying on a business in Australia.

The opposition has indicated its broad support of the measures and it is expected that the Bill will pass without significant amendment.

The new Attorney-General, Mark Dreyfuss, has also committed to introduce broader changes to the Privacy Act 1988 (Cth) sooner rather than later, with the Government’s review scheduled to be completed before the end of 2022. This comes after a broad review of the Australian privacy regime was commenced by the previous Federal Government in 2019 but never completed.

On 24 October 2022, the ICO issued a penalty notice (MPN) to Interserve Group Limited (Interserve), imposing a fine of £4.4m for violations of the GDPR (the violations were pre-Brexit).
The ICO found that Interserve had failed to put appropriate technical and organisational measures in place to secure personal data (in contravention of Articles 5(1)(f) and 32 GDPR) for a period of ~20 months.

The Incident

The incident followed what is proving to be a familiar fact pattern. A phishing email was sent to a group employee which was designed to appear as though the attached document needed urgent action. Subsequent download and ZIP extraction resulted in the installation of malware onto the workstation giving the threat actor access to that workstation (Patient Zero). This was flagged by Interserve’s end point protection system, which reported automatic removal of malware had been successful. Interserve took no further action to verify this, and the threat actor continued to have ongoing access to the workstation.

Following initial access, a server was compromised which was then used to “move laterally” within the Interserve estate (i.e., moving from the initial point of compromise to other parts of the victim’s IT estate). In the subsequent days, the threat actor compromised 283 systems and 16 accounts (12 being privileged admin accounts) across the estate. A privileged account was then used by the threat actor to uninstall Interserve’s anti-virus solution to prevent detection of malware used by the threat actor. The attacker then compromised four HR databases containing data of 113k employees and former employees. The databases were encrypted and rendered unavailable to Interserve. Regulatory notification followed to the NCA, the NCSC and the ICO.

The personal data held on the compromised databases comprised a common HR data set, including employees’ and former employees’: telephone numbers; email addresses; national insurance numbers; bank account details; marital status’; birth dates; education; countries of birth; genders; number of dependants; emergency contact information, and salary. The databases also held special category personal data including ethnic origin; religion; details of disabilities; sexual orientation, and health information relevant to ill-heath retirement applications. Interestingly, each of these items of information was not necessarily held for each of the 113,000 individuals, rather these categories of information were recorded in the relevant databases. Under Article 33(1) GDPR an organisation is only obliged to be able to describe the approximate categories and number of personal data records when notifying the ICO which appears to have been the approach adopted by Interserve.

Digest of points to note in the MPN

The MPN is littered with useful insights into the ICO enforcement and provides further detail around what the ICO expects with regards to the principle-based obligations in Article 5(1)(f) and 32 GDPR. We found the following points of particular interest:

• % of revenue. On the face of it, this is a sizeable fine issued to a non household name controller for perceived failings in information security. Dig a little deeper and, in fact, the level of fine appears to be a relatively small percentage of Interserve’s last reported revenues (less than 1/5th of 1%).

It is nevertheless a significant amount of money and the reputational damage arising from a public fine was also taken into consideration by the ICO when setting the fine. The fact that the fine is a relatively small percentage of revenues may indicate that the new ICO John Edwards, favours a less aggressive approach to enforcement than his predecessor Elizabeth Denham, at least when it comes to setting the level of fine. Lower fines are also less likely to result in successful appeals and tie up the ICO’s enforcement team with legal arguments.

A key open legal question remains whether the correct maximum fine when calculating fines under the UK GDPR (NB this MPN was issued under EU GDPR) is either a) the greater of 2% of turnover or £8.7 million; or b) the greater of 4% of turnover or £17.5 million (in each case where turnover is total worldwide annual turnover of the preceding financial year). The ICO has previously taken the position that the higher limit applies though this has not yet been tested on appeal and there are good arguments that the lower maximum should apply.

• One group controller to rule them all: Interserve was held to be the relevant controller for the purpose of enforcement, regardless of the fact the incident and the security failings were applicable across numerous group companies. Interserve was the parent company, it was responsible for info-sec for the group and employed individuals working in information security. Enforcement against multiple entities in the same group is complicated and time consuming. It is much simpler for the ICO to target the parent company when that company is responsible for info sec for the entire group.
• Paper based compliance represents a small and incomplete part of the picture. Central to the decision (and another identified recurring point of failure) was that Interserve had extensive info-sec policies and standards however these policies were not implemented nor were they subject to appropriate oversight (despite the fact the exec were aware of issues with the Interserve estate). While policies and procedures are an essential part of any compliance programme as the “paper shield”, without the resources and budgets needed to implement and oversee them effectively, they can become a liability for controllers providing an easy way for regulators to prove breach. Employee training remains a key consideration for the ICO in the context of post incident enforcement. The Interserve MPN is yet another reminder of the importance of regular and effective training.

• Period for assessing duration of infringement / enforcement: the “relevant period” for the ICO’s assessment around the duration of the infringement was held to start at the time Interserve became the relevant controller (following the winding up of another group company) and did not end until remediation was complete. This emphasises the importance of remediating any gaps in security measures promptly to meet the legal standard of care. Any delay to remediation will extent the duration of the infringement, aggravating the risk of fines and also potentially compounding losses caused to data subjects. The MPN also provides an insight into the timing of, and procedural steps around, ICO enforcement. The Notice of Intent was not served on Interserve for almost 2 years after the Article 33 notification was made to the ICO. A month later, Interserve provided written representations in response to that notice. The ICO updated the notice and invited supplemental representations, which were made by Interserve. The final procedural step was an ICO meeting ~4 weeks before the MPN was published.

• What was the risk of harm to the individuals? an eagle-eyed reader may question what was the risk to the data subjects here? There was no evidence of exfiltration, and one view may be that the threat actor applied encryption in an attempt to extort money from or cause nuisance to Interserve rather than to cause harm to the individuals (e.g., fraud).

The ICO found that all the data subjects had their personal data processed unlawfully and the processing had the potential for concern, anxiety and stress, due to: (a) data had been accessed by criminal actors with malicious intent; (b) the personal data compromised included data which was commonly used to facilitate identity/financial fraud (home addresses, bank account details, pay slips, passport data and national insurance numbers); (c) special category data was compromised – it is particularly sensitive (per Recital 51). Employees may be content to share with their employer, they would not want this data accessed by malicious individuals: (d) compromised data included salary details, which enables social and financial profiling which is dangerous in the hands of threat actors; (e) while there was no evidence of exfiltration, the ICO could not rule out this possibility and the risks of exfiltration remain significant as privileged accounts could exfiltrate data / advanced groups can prevent detection of exfiltration / measures that can identify exfiltration (firewall filtering and logging) were not implemented until after the incident.

• What should you be discussing with your Info-Sec team? While the ICO MPN does not necessarily reflect the legal standard of care (as the ICO does not make the law) it is an indication as to the ICO’s view as to the legal standard of care at the date of the incident. In particular, the ICO considers that the following gaps and deficiencies fell short of the legal standard of care required by Articles 5(1)(f) and 32 GDPR:
• • outdated operating systems/protocols;
  • inadequate end point protection (outdated / firewalls not enabled);
  • no pen tests conducted for two years prior to the incident;
  • inadequate investigation by the info-sec team; and
  • poor privileged account management.

It would be prudent for organisations to check that their own IT estates do not suffer from the same shortcomings. As with previous decisions regulatory guidance/standards (NIST / NCSC) continues to be an appropriate benchmark. The MPN strongly implies that Interserve spent considerable amounts to remediate in accordance with ICO expectations. Remediation before a cyber incident is invariably less costly, stressful and damaging to an organisation’s reputation and balance sheet compared to remediation after a cyber incident.

We continue to frequently advise clients both on incident response together with pro-active cyber assurance and resilience. If you need any advice in this area, please do reach out to your DLA contact.

Authors: Ross McKean (Partner and co-chair of the UK data protection and cyber security practice) and Henry Pelling (Senior Associate in the DLA data protection and cyber security practice).