Chapter 5: Identify and Assess Risks PDF

5. IDENTIFY AND ASSESS RISKS The ‘key takeaways’ from this chapter are the importance of: (a) having the senior management of an organisation have an understanding of risks, and review them on a regular basis; (b) identifying the potential data protection and...

5. IDENTIFY AND ASSESS RISKS The ‘key takeaways’ from this chapter are the importance of: (a) having the senior management of an organisation have an understanding of risks, and review them on a regular basis; (b) identifying the potential data protection and information security risks in the business processes of each department of the organisation; (c) assessing the data protection and information security risks within the organisation, brought to the organisation by its data intermediaries and the regulatory requirements in connection with those risks; (d) the organisation’s PDPA Project Team establishing a baseline of the vulnerabilities, gaps and exposures to data protection related risks; and (e) escalating key issues to senior management in preparation for the design of a risk-based DPMP implementation strategy. 60 5.1 Introduction to risk and risk management _________________________________________________________________________ 5.1.1 The senior management of an organisation should have an understanding of risks, and review the risks on a regular basis to take into consideration changes in business models, regulations, technology and other factors. In general, an organisation may consider 4 general categories of risk: (a) Financial: risks affecting the financial processes of the company (e.g., accounting and reporting, tax, etc.); (b) Strategic: risks affecting achievement of the strategic objectives of the company (e.g., governance, strategic planning, major initiatives, etc.); (c) Operational: risks affecting the operations of the organisation (e.g., sales & marketing, supply chain, etc.); and (d) Compliance: risks affecting the company’s compliance with regulatory requirements (e.g., legal, code of conduct, etc.). 5.1.2 Data protection may have implications with respect to all 4 categories of risk. Nonetheless, for the purposes of this guide, we will be focusing on personal data protection related risks. 5.1.3 For such risks, generally, risks levels may be determined by considering the following three industry-recognised parameters of impact in an event the data is compromised: (a) Confidentiality (C): Risk to organisation or individuals arising from unauthorised or inappropriate disclosure. For information to be confidential, the access to some information needs to be restricted because it could harm interests of the stakeholders. (b) Integrity (I): Risk to information quality or corruption. For information to be useful and serve the purpose, it must be as accurate and complete as possible. (c) Availability (A): Risk to information not being available to intended users. For information to be useful and serve the purpose, it must be available when it is needed and in a form that is accessible by the intended users. 5.1.4 Risk management is: (a) the identification, assessment and prioritisation of risks followed by (b) actions to minimise, monitor and control the probability of the risky event occurring and/or its impact if it does occur 5.1.5 The objective of risk management is to help ensure uncertainty does not deflect the organisation from its business goals. In other words, if an organisation does not manage its risks it may be either too timid to move forward well with its business goals 61  or distracted from its business goals when a risky event occurs and the organisation suffers loss as a result of it. On the other hand, if an organisation decides at the outset how it will manage its risks, including what provisions it may make to deal with a risky event if and when it occurs, the organisation can move forward confidently to achieve its business goals. 5.1.6 A risk is the potential for loss, harm or negative effect on a situation. In the case of compliance with the PDPA, a risk is the potential for a failure to comply with the PDPA. For example, there is a risk of failing to comply with the protection obligation under the PDPA: (a) if malware exploits a weakness resulting from a failure to apply update patches to software; or (b) if staff are allowed to take documents containing personal data out of the office and they carelessly leave the envelope or bag containing them in a coffee shop or on the train, which may lead to the exposure of personal data (data breach) which could then expose the victim of the data breach to the possibility of identity theft. 5.1.7 Depending on the context, the term ‘risk’ in this document may: refer to an identified security gap in a system, to a weakness, or a vulnerability; refer to an expected or possible threat to a system; refer to the likelihood of an event, incident or attack; refer to a compliance gap regarding the PDPA; refer to the risk of an investigation by or complaint to PDPC; or refer to implications or impact of an incident, on the organisation, on a system, or on an individual. 5.1.8 A threat is something with the potential to do harm. Malware and spyware, for example, are threats to an IT system. Other examples of threats are careless employees who, for example, remove paper documents from the office and accidentally leave them in a coffee shop or on a bus, and disgruntled employees. Former employees who deliberately seek to do harm to an organisation are also threats. 5.1.9 A vulnerability is a weakness / gap / shortcoming that can be exploited by a threat – in other words, it can lead to a potentially harmful situation. For example, an inadequate firewall or failing to apply update patches to software are IT vulnerabilities. Weak internal policies that allow employees to take paper documents out of the office and failing to terminate the log-in credentials of employees immediately after they leave the organisation also give rise to vulnerabilities. 5.1.10 A risk in the case of compliance with the Protection Obligation under the PDPA is the potential for a failure to comply with the PDPA as a result of a threat exploiting a vulnerability (see 5.1). Therefore, it is important that organisations manage such risks with the objective of ensuring that the organisation does not fall short of its goal of 62 complying with the PDPA. Working out how to do so is a fundamentally important part of developing a DPMP. 63 5.2 The place of data classification in risk management _________________________________________________________________________ 5.2.1 A data classification policy is a tool for categorising data in accordance with its sensitivity and/or confidentiality. Data classification: (a) helps an organisation to assess risk; (b) is an important element in drafting or executing a personal data protection policy, an information security policy and a data retention policy; and (c) plays a part in incident and security management procedures. 5.2.2 A data classification policy allows the appropriate level of access control and protection measures to be developed and implemented. A well-planned data classification policy treats data consistently, makes essential data easy to find and retrieve and governs data with the appropriate level of access control. This can be particularly important for risk management, legal discovery and personal data protection. 5.2.3 Here are some considerations when developing and implementing a data classification policy: (a) what levels of data classification to adopt – for example, ‘confidential and sensitive’, ‘confidential’, ‘internal use only’, ‘unrestricted’; (b) how to define the parameters for each level of data classification so staff can classify data consistently; (c) who is responsible for data classification and who is accountable for it; (d) for each data classification level, what access rights to the relevant data should be granted to staff; (e) what protection the organisation should implement for each level of data classification; and (f) what information security requirements the organisation should attach to each level of data classification. 5.2.4 Information security requirements and other controls adopted should correspond to the risk level and nature of the data, and should include both digital and non-digital solutions e.g. encryption and access controls. 64 5.3 Risks relating to the DP and DNC provisions _________________________________________________________________________ 5.3.1 One example of risk in relation to personal data is the risk relating to non-compliance with the PDPA – that is, the risk of an organisation failing to comply with: (a) one or more of the eleven obligations under the DP provisions in the PDPA (see 1.2); or (b) the DNC provisions in the PDPA (see 1.3). 5.3.2 Here are some examples of instances of non-compliance with the PDPA: (a) Consent Obligation: failure to obtain consent, forced consent / no choice given, withdrawal of consent prohibited, no consent given for disclosure to third parties so consent to third parties is unauthorised, indiscreet conversations, misleading purpose, unauthorised secondary purpose, negligent usage / misuse; (b) Notification Obligation: notification required but not given; (c) Purpose Limitation Obligation: unreasonable / excessive collection in view of the stated purpose; (d) Accuracy Obligation: inaccurate and/or outdated personal data, error in processing; (e) Retention Limitation Obligation: unlimited retention, improper disposal; (f) Protection Obligation: unsecured handling of personal data, failure to have adequate cybersecurity measures to protect personal data, failure to have policies and processes to protect data, insecure transmission of data; (g) Access and Correction Obligation: denial of access to or correction of personal data without reasonable basis; (h) Transfer Limitation Obligation: failure to ensure that personal data is transferred to another country only according to the requirements prescribed under the PDPA; (i) Accountability Obligation: no DPO appointed, no documented or inadequate internal policies and processes; (j) Data Portability Obligation: rejection of a data porting request without reasonable basis; (k) Data Breach Notification Obligation: failure to notify a notifiable data breach; and 65 (j) DNC provision: failure to check the relevant DNC registry before sending a marketing message. 66 5.4 Risks relating to business processes _________________________________________________________________________ 5.4.1 Examples of areas of risk in relation to personal data include: (a) risks relating to non-compliance with the PDPA; (b) risks in business processes; (c) risks where third party / service vendors are involved / concerned; and (d) risks of processing personal data electronically. 5.4.2 The first step in developing a DPMP is to build a data inventory map (see 4.1.1 ) and or a data flow diagram. The second step is to identify potential data protection risks in the business processes that handle the personal data. Some of the issues that an organisation needs to examine in order to identify whether there are exposures or gaps in each department’s specific business processes include: (a) whether there is unauthorised collection of personal data by the organisation – as to whether the collection of personal data is unauthorised, the organisation needs to consider the Consent Obligation, the Notification Obligation and the Purpose Limitation Obligation to determine: (i) whether express consent is required and, if so, whether the organisation notifies the individual of the purpose for processing personal data; (ii) whether the organisation may rely on the individual being deemed to have consented to the processing of personal data; or (iii) whether there is an applicable exception from the need for consent; (b) whether there is excessive collection of personal data by the organisation (because an organisation is not permitted to, as a condition of providing a product or service, obtain consent for collection, use, disclosure and storage of personal data beyond what is reasonable to provide the organisation’s products and services to an individual; also to obtain consent, the individual needs to be notified of the purpose(s) of the collection, use or disclose of personal data) – in other words, the organisation needs to consider whether it is collecting more personal data than is actually needed for the notified purpose(s). One quick test to check for excessive collection of personal data is to ask (about each piece of personal data) ‘could the organisation fulfil the notified purpose(s) if it did not have this particular piece of personal data?’ If the answer is ‘yes’, or if the answer is ‘but we need it just in case … ‘, the collection of that piece of personal data is likely excessive; 67 (c) whether the purpose for collecting, using, disclosing and storing the personal data are reasonable – as to whether the purpose for collecting personal data is reasonable an organisation must consider whether it is processing it only for purposes that a reasonable person would consider appropriate in the circumstances; (d) whether there are any secondary purposes for which the organisation uses, discloses and stores the personal data – that is, any purposes in addition to the purpose(s) notified by the organisation to the individual at the point of collection or on which the organisation is relying on deemed consent or for which there is an exception to the need for consent; Secondary purposes may arise where, for example, one department within an organisation processes personal data for a particular notified purpose, but another department subsequently processes it for a different purpose. A data inventory map, where every department includes its own business processes conscientiously, is crucial to identifying any secondary purposes. The organisation can then ensure that either it gets any necessary consent for the identified secondary purposes or stops processing the personal data for those purposes; (e) whether there is any personal data of a sensitive nature collected by the organisation: some personal data is inherently more sensitive than other personal data because, for example, it may enable identity theft and/or financial crimes or because an individual would have a strong interest in keeping it confidential – such personal data includes NRIC numbers, payment card details and financial / health / medical information – and it therefore requires a higher level of protection when handling and storing it in order for the organisation to comply with the protection obligation; (f) whether the personal data is, or needs to be, encrypted or otherwise secured at the point of collection and/or when the organisation stores the personal data – the organisation should consider, for example: (i) whether the personal data is sensitive and therefore needs a higher level of protection than would otherwise be the case; and (ii) if the personal data will be collected and/or stored by a data intermediary (for example, because an IT vendor hosts the organisation’s website and databases), whether the organisation has done appropriate due diligence on the data intermediary and, after concluding that it is capable of complying with the PDPA (that is, the organisation has concluded that the vendor can be trusted), has entered into a written contract with it that includes clauses protecting the organisation from personal data protection related risks introduced by the data intermediary. (iii) It is important to note that when an organisation outsources any data processing to a data intermediary the organisation continues to be 68  obliged to make reasonable security arrangements to protect personal data in its possession or under its control; (g) whether a vendor / potential vendor that is / will be a data intermediary is located outside of Singapore – if so, the organisation will need to consider whether the vendor’s location gives rise to any particular risks (and, if so, consider selecting a vendor elsewhere) and make sure that it complies with the Transfer Limitation Obligation; (h) whether the organisation controls access by its staff to the personal data on a ‘need to know’ basis and that the staff who do have access to it are authorised to process the personal data for a particular specified purpose – here the organisation’s data classification policy (see 5.2) is crucial to determining which staff should have access to personal data that is classified as ‘confidential’ (after they have signed an appropriate confidentiality agreement); (i) whether there are points in the process where employee carelessness / negligence could result in failure by the organisation to comply with the Protection Obligation; (j) whether there are any points at which personal data is disclosed and that disclosure: (i) is not authorised; or (ii) is excessive, so that the organisation may fail comply with the Protection Obligation; (k) whether the organisation has a policy about how long it should retain each type / category of personal data that complies with the Retention Limitation Obligation; and (l) whether the organisation has processes in place to ensure that personal data is disposed of securely so that the organisation complies with the Protection Obligation. 69 5.5 Risks relating to data intermediaries _________________________________________________________________________ 5.5.1 Areas of risk in relation to personal data include risks where third party / service vendors are involved / concerned – these are external risks. 5.5.2 The enforcement decisions published by the PDPC show clearly that a majority of cases involve a failure by an organisation to comply with the Protection Obligation. In many of those cases, the failures resulted from the actions or inactions of data intermediaries and/or a lack of clarity in the obligations of the data intermediary in connection with the Protection Obligation vis-à-vis the obligations of the organisation in connection with the Protection Obligation. In other words, the organisation did not have adequate governance principles in place to manage the risks introduced to organisations by data intermediaries. 5.5.3 Here are some of the things to look out for when engaging data intermediaries (these include failures observed from the cases in PDPC’s published enforcement decisions: (a) the IT system/network of the data intermediary being hacked and the hacker gaining access to personal data under the control of the organisation; (b) unauthorised disclosure of personal data by the data intermediary; (c) data intermediary staff not complying with data intermediary’s information security policy or practices by bringing their own devices to work; (d) insufficient information security controls in the data intermediary’s IT system; (e) poor or no written contract between the organisation and the data intermediary leading to violation by the data intermediary of the organisation’s information security requirements; and (f) lack of oversight by the organisation that engaged the data intermediary. 5.5.4 An organisation has the same obligations under the PDPA in respect of personal data processed on its behalf by a data intermediary as it would have if the organisation processed the personal data itself. This means that when an organisation outsources any data processing to a data intermediary the organisation continues to be obliged to make reasonable security arrangements to protect personal data in its possession or under its control. 70 5.6 Risks relating to electronic processing of personal data _________________________________________________________________________ 5.6.1 Areas of risk in relation to personal data include the risks related to the processing of personal data electronically. 5.6.2 Storing personal data in IT systems and making personal data available via the Internet offers many advantages as compared with non-electronic methods of storing personal data and making it available via the Internet. However, organisations must be aware of potential cyber security and data breach risks, as well as the issues that may arise from such risks eventuating. 5.6.3 The Protection Obligation requires organisations to make ‘reasonable security arrangements’ to prevent unauthorised access, etc. (What is reasonable likely depends on the sensitivity of the relevant personal data.) Therefore, as part of developing its DPMP, an organisation must consider what controls it should put in place to reduce the risks and likelihood of cyber security incidents and personal data breaches. 5.6.4 There is a difference between a ‘cyber security incident’ and a ‘personal data breach’. 5.6.5 A malware attack is a cyber security incident because it puts data at risk of unauthorised exposure. 5.6.6 If an incident involves personal data (versus involving only, say, commercial data held by an organisation) and there is unauthorised access, collection, use, disclosure, copying, modification, disposal, etc. of that personal data; or the loss of any storage medium or device on which personal data is stored in circumstances where the unauthorised access, collection, use, disclosure, copying, modification or disposal of the personal data is likely to occur, the security incident is a data breach. 5.6.7 Cyber security incidents and data breaches involving personal data in an IT system or made available through the Internet can be caused by a variety of means, including: (a) hacking and other unauthorised access to a database; (b) malware, including viruses, spyware and ransomware; (c) social engineering – which includes phishing scams (such as an email that invites the recipient to click on a link that takes the recipient to a website that 71  looks real but is fake and which asks the recipient to enter personal data into that website); (d) loss or theft of mobile devices, including laptop computers, tablets, mobile phones and external hard-drives (USB / thumb drives) that contain personal data that is not password protected and/or encrypted; (e) failures of, and weaknesses in, program code that results in personal data being revealed to incorrect parties – for example, a bug in an online portal that allows an individual to access personal data about another individual; (f) compromised network devices, such as compromised servers and routers; (g) not disposing of electronic data properly, such as not properly deleting personal data from hard-drives (for example, by degaussing) before disposing of the equipment that houses the hard-drive (for example, laptops, tablets, printers, photocopiers, scanners) – degaussing is the process of reducing or eliminating an unwanted magnetic field (or data) stored on hard-drives using, in effect, a powerful magnet; or (h) transmitting personal data to an unintended / wrong recipient, such as emailing personal data to the wrong email address – allowing an email program to auto- complete email addresses is a common way in which this occurs. 72 5.7 The seven common mistakes made by organisations _________________________________________________________________________ 5.7.1 The seven common mistakes that organisations make in connection with compliance with the PDPA are likely to be: (a) insufficient data protection measures – that is, no comprehensive policies and practices (such as those developed and implemented via a DPMP) are adopted by an organisation. Such a failure in operational practices can result in failure to comply with any one or more of the obligations in the PDPA. (b) little or no information security practices. This generally leads to a failure to comply with the Protection Obligation. It occurs most often when an organisation has either: (i) not focused on compliance with the PDPA at all; or (ii) views PDPA compliance as merely a legal exercise rather than as an operational requirement with a legal element and a security element that includes technical controls, administrative controls and physical controls. (c) an IT infrastructure that is known to be vulnerable to online threats but action is not taken to remedy those vulnerabilities. This is another mistake that leads to failure to comply with the Protection Obligation. (d) improper training, including data protection and information security policies and practices not being communicated to the organisation’s employees; (e) disjointed practices and processes within the organisation, such as where there is a break down in the process of one department in the organisation making personal data available to another department in the organisation; or where, more generally, the organisation lacks streamlined and organised administrative processes. Depending on the circumstances, this can result in the organisation failing to comply with various obligations under the PDPA. Such disjointed practices and processes can be identified and then avoided by conscientious data inventory mapping of all business processes; (f) leadership complacency regarding compliance by the organisation with the PDPA, which inevitably results in complacency among management and operational staff – leadership complacency is characterised by an ‘it won’t happen to us’ mentality and a ‘we’ll deal with it if and when it happens’ attitude; 73 (g) lack of oversight of third parties – that is, data intermediaries – and having poor (or no) contracts with them; and (h) physical security lapses. 74 5.8 Assessing / measuring risks and ranking them – risk rating/scoring _________________________________________________________________________ 5.8.1 Organisations ordinarily tackle risk management by first treating the highest-ranked identified risks. (Treating the risk means that the organisation decides to modify the risk, retain the risk, avoid the risk or share the risk with a third party – see 6.2) This ranking is typically done by using a risk assessment framework. A risk assessment framework – also known as ‘risk rating/scoring’ – is a technique used to rate each individual risk based on a combination of: (a) the impact on the business if the risk occurs (i.e. the organisation’s assessment of the likely loss /magnitude of the loss it would suffer if the risk occurs); and (b) its assessment of the likelihood of the risk occurring. 5.8.2 Each organisation should use a risk assessment framework that it considers to be appropriate for its objectives and needs. When deciding which framework to use, an organisation should consider legal and regulatory requirements. For example, if the organisation is regulated by the Monetary Authority of Singapore (MAS), the risk assessment framework it is to use might be mandated by MAS. When defining risk criteria, an organisation should also consider industry best practices and guidelines and project-specific requirements. 5.8.3 One way an organisation can do the rating/scoring under a risk assessment framework is by using for each of the two factors: (a) a quantitative approach where the organisation uses numbers – for example, ‘a potential impact of $1 million loss of revenue with a probability of occurring of 0.2’; or (b) a qualitative approach where a relative scale is used by the organisation to indicate the magnitude of potential impact such as from lowest to highest – for example, ‘potential impact is ‘very high’, with a probability of occurring of ‘low’’. The resulting scores enable the organisation to compare and prioritise the risks from the most severe to the least severe. The person or team members carrying out the risk assessment need not necessarily be the DPO or top management. The person or team members should be familiar with or working in the domain. For the cyber security domain for example, only a person who is familiar with or working in the cyber security domain would be able to have a good sense if the risk levels for a cyber threat is low or high. 5.8.4 Another way an organisation can do the rating/scoring under a risk assessment framework is by simply assigning a number to indicate the magnitude of the potential impact of a risk and another number for its likelihood, multiply the two numbers for each risk and then rank the risks in terms of the resulting number. The following is an example under this approach: 75 (a) the likelihood of a risk occurring may be assigned a number on, for example, the following scale: (i) 1 = rare: the organisation assesses the likelihood of the risk occurring as remote and not conceivable and assigns a value of ‘1’ to it; (ii) 2 = unlikely: the organisation assesses the likelihood of the risk occurring as conceivable but there is no indication or evidence to suggest the possibility of the risk occurring in the near term and assigns a value of ‘2’ to it; (iii) 3 = possible: the organisation assesses that it is possible that the risk will occur in the near term and assigns a value of ‘3’ to it; (iv) 4 = likely: the organisation identifies indications that suggest that the risk is expected to occur in the near term and assigns a value of ‘4’ to it; and (v) 5 = almost certain: the organisation identifies indications that suggest a high probability of the risk occurring in the near term and assigns a value of ‘5’ to it; (b) meanwhile the impact suffered by the organisation if the risk occurs may also be assigned a number on, for example, the following scale: (i) 1 = insignificant: if the risk occurs, the organisation assesses its likely impact as remote and no impact and assigns a value of ‘1’ to is; (ii) 2 = minor: if the risk occurs, the organisation assesses that it may suffer some inconvenience but the organisation does not see any indication or evidence to suggest major damage to the organisation that will result in financial or reputational loss and assigns a value of ‘2’ to it; (iii) 3 = moderate: if the risk occurs, the organisation assesses that it will experience some inconvenience or consequences but indications suggest that damage can be overcome or recovered in a short time and assigns a value of ‘3’ to it; (iv) 4 = major: if the risk occurs, the organisation assesses that it will experience significant consequences and indications suggest that damage will be widespread and result in loss of financial, reputation and support from stakeholders (see 3.4.5 regarding stakeholders) and assigns a value of ‘4’ to it; and; (v) 5 = severe: if the risk occurs, the organisation assesses that it will suffer severe consequences and indications suggest that damage sustained may result in the organisation either not being able to operate as usual for a prolonged period of time or not be able to overcome that damage as assigns a value of ‘5’ to it; and 76  (c) for each risk, the organisation multiplies the number assigned to that risk in accordance with paragraph (a) by the number assigned to it in accordance with paragraph (b) and then ranks the risks in the order to the resulting numbers. 5.8.5 For the above example, each criteria is based on a 5-point scale. This means that 1 is the lowest possible risk rating/scoring and 25 is the highest possible risk rating. The organisation might decide that it would accept all risks if the result is less than, for example, 15 and that risks with risk ratings of 15 and above would be given immediate priority. The organisation would then consider which risk treatment option (i.e. risk modification/reduction, risk retention, risk avoidance or risk sharing) to adopt. (see 6.2). 77 5.9 Next steps after ranking risks – reporting to senior management _________________________________________________________________________ 5.9.1 The PDPA Project Team established by an organisation needs to provide the DPO with sufficient support to enable the DPO to be able to ensure that all departments within the organisation that collect, use, disclose and store personal data contribute to building a data inventory map, a data flow diagram, a risk assessment and risk ranking (based on the risk scores) to determine the order of priority of each risk. The DPO must then: (a) collate and prioritise all of the identified risks in connection with compliance with the PDPA; and (b) summarise them in a report for senior management of the organisation and/or PDPA Project Team established by the organisation 5.9.2 In some organisations, its PDPA Project Team and senior management are the same group of people or at least have a significant degree of overlap. In other, usually larger organisations, the PDPA Project Team reports to senior management, even if it has a small degree of overlap with senior management 5.9.3 After preparing the report described in 5.9.1 the DPO should present it to the PDPA Project Team for feedback, approval, budget, escalation to more senior management and/or whatever other functions senior management of the organisation have decided should be within the purview of the PDPA Project Team. Such a report ensures that senior management of the organisation and/or the PDPA Project Team have clear visibility of the current state of the organisation’s compliance with the PDPA and the data protection gaps, exposure and risks of which they need to be aware. 5.9.4 From this point onwards, the PDPA Project Team or the DPO (as the case requires) should engage senior management regularly and update senior management about the status of the development and implementation of the DPMP for the organisation. In particular, issues that are of concern to senior management or that need senior management decision and/or direction on the next course of action should always be escalated to senior management. The benefits of engaging senior management include their support for the organisation’s data protection efforts. Selected individuals from senior management can champion such efforts making a significant difference on their outcomes. This includes senior management ensuring the right level of priority and resources are accorded by the organisation to its data protection efforts. 5.9.5 Other than the initial developing of a DPMP, the the PDPA Project Team or the DPO (as the case requires) should ensure there is regular monitoring of personal data protection risks. 5.9.6 While senior management engagement is invaluable while ‘staff work’ is being done on developing and implementing a DPMP for the organisation, senior management remain responsible for compliance with the PDPA: the tasks of compliance and risk management can be delegated, but not the responsibility for it. 78