Managing Risks PDF

6. MANAGING RISKS The ‘key takeaways’ from this chapter are that: (a) once an organisation has identified the risks associated with the collection, use, disclosure and storage of personal data, it can put controls in place to treat (manage) them; (...

6. MANAGING RISKS The ‘key takeaways’ from this chapter are that: (a) once an organisation has identified the risks associated with the collection, use, disclosure and storage of personal data, it can put controls in place to treat (manage) them; (b) the organisation can implement a combination of phase controls (that is, the prevention phase, the detection phase and the response phase) and functional controls (that is, proactive / preventative controls, detective controls and reactive / corrective controls) to minimise risk; (c) it is crucial for an organisation to manage the risks created by data intermediaries and other third party risks, including by due diligence and contractual protection; (d) Data Protection by Design (DPbD) and Data Protection Impact Assessment (DPIA) can be used to manage risks proactively; and (e) The term ‘risk’ has different meanings in different context, and it is important for the DPO to be aware of such differences. 79 6.1 Developing a risk management strategy and controlling risks _________________________________________________________________________ 6.1.1 An organisation needs to decide how to manage risks it identifies – in other words, it needs to develop a strategy to implement its DPMP. 6.1.2 Depending on the context, the term ‘risk’ in this document may refer to: an identified security gap in a system, to a weakness, or to a vulnerability; an expected or possible threat to a system; the likelihood of an event, incident or attack; a compliance gap regarding PDPA; the risk an investigation by or complaint to PDPC; the implications or impact of an incident on the organisation, on a system or on an individual; etc. 6.1.3 An organisation manages its personal data protection related risks by modifying, retaining, avoiding and/or sharing risks. It does so by applying technical, administrative and physical controls / rules. The objective is to minimise, monitor and control: (a) the likelihood of the risk occurring; and (b) its impact if it does occur. 6.1.4 The DPO may need expert risk management input and should certainly call on the assistance and advice of any risk officers within the organisation to determine the appropriate actions and controls to implement in the situations and environments relevant to the organisation. 80 6.2 Four common ways an organisation responds to risk _________________________________________________________________________ 6.2.1 There are four common ways in which an organisation can respond to a risk, namely: (a) risk modification/reduction: the organisation creates actions and controls (processes) to reduce the likelihood or impact of the risk to an acceptable level – in other words, it develops and implements internal controls / rules to reduce the likelihood or impact of the risk; (b) risk retention: the organisation accepts the risk and continues with ‘business as usual’ with no new internal controls / rules in order to pursue an opportunity – an organisation might do this: (i) where it assesses the costs of new internal controls / rules to exceed the costs or damage of a risk occurring; (ii) where it assesses the costs of new internal controls / rules to be out of proportion to its assessment of the relevant risk having a low probability of occurring and a low impact if it does occur; or (iii) where new internal controls / rules may make it impossible to pursue an opportunity and it assesses that the value of the opportunity exceeds the risks of pursuing it. For example, an organisation with a large fleet of motor vehicles might assess the costs of insurance premiums if ;t has a control / rule that all vehicles must be comprehensively insured to exceed the costs borne by the organisation if it occasionally suffers a loss through a vehicle being damaged, an event that has a low impact if it does occur. Risk retention is not a common way of managing regulatory risk – that is, the risk of not complying with a known regulatory requirement – because regulators typically expect an organisation to have made at least a reasonable attempt to comply with the law; (d) risk avoidance: the organisation removes the source of the risk by deciding to stop an existing activity or to stop performing an existing activity; and (e) risk sharing: the organisation shares the risk with others by, for example, taking up insurance, purchasing a financial product (such as an option or a more sophisticated and specialised instrument for risk financing), entering into a joint venture or partnership or outsourcing the activity to which the risk is attached (however, risk sharing may address the cost issue, but it may not apply to regulatory responsibilities, e.g. trying to ‘share risk’ with a data intermediary to reduce the organisation’s own risk in terms of complying to the PDPA). 81 6.3 Technical controls, administrative controls and physical controls _________________________________________________________________________ 6.3.1 Controls that an organisation might apply to treat or mitigate risks in connection with personal data follow into the following three categories: (a) technical controls use technology as a basis for controlling the access to, and use and/or disclosure of, personal data throughout a physical structure and over a network. Examples of such controls include: anti-virus programs, data loss prevention (DLP) tools, anonymisation of personal data, encryption of personal data, smart cards (where data is encrypted and embedded in the chip on the card), network authentication, access control lists (ACLs), password management rules, penetration tests (that is, an authorised simulated attack on an IT system to identify its weaknesses, if any, that might allow a hacker to have access to it) and vulnerability assessments (that is, testing to uncover weaknesses in an IT system and to recommend appropriate remediation or mitigation to remove or reduce risk); (b) administrative controls define the human factors of data protection. They involve all levels of personnel within an organisation and determine which users have access to what resources and information, what they do with them and the consequences if they do not obey the controls / follow the rules. Examples of such controls include: (i) policies (such as a personal data protection policy, information security policy, data retention policy, social media policy, bring-your-own- device (BYOD) policy, HR policies and procedures) or implementing a clean desk policy, protecting service counters and requiring all paper files and documents to be stored in locked cabinets; (ii) confidentiality obligations of employees under non-disclosure agreements signed by employees, requirements in employment contracts for employees to comply with all company policies and procedures and for disciplinary procedures to apply if they do not do so; and (iii) contracts, such as contracts with data intermediaries requiring compliance with the organisation’s policies and/or with contractual terms supporting the organisation’s compliance with the PDPA, audit rights and the obligation to co-operate with the organisation in connection with any complaints, investigations and data breaches and non-disclosure agreement with other third parties with whom the organisation shares personal data; (c) physical controls are data protection measures used to deter or prevent unauthorised physical access to, and use and/or disclosure of, personal data: examples include restricting access to an organisation’s premises by employing 82  security guards and/or protected sign-in procedures, picture IDs, badges and access passes, locked and dead-bolted doors. 6.3.2 Technical, administrative and physical controls are all in anticipation of a risk or event, but have different effects: (a) proactive / preventative: they are implemented with the objective of preventing a riskit from occurring. It is in the interest of the organisation to put in as many proactive / preventative controls as possible, but their use does need to be balanced against the organisation being able to operate efficiently and effectively while managing its risks; (b) detective: they are intended to detect a risk when it occurs and thereby give the organisation the earliest possible warning that the risk has occurred, but they cannot stop the event; and (c) reactive / corrective: they are intended to remedy the situation after the risk has occurred. 6.3.3 Administrative controls need not be, and should not be, accessible to staff only by them reading detailed and lengthy policies and practices documents. To operationalise controls it very frequently makes sense to lift a few simple rules out from the formal policies and practices documents and to present them to relevant staff as a simple and straightforward set of requirements or instructions – as standard operating procedures (SOPs). All SOPs should be tailored for the organisation’s specific requirements, but here are two examples: (a) in connection with the Consent Obligation, Notification Obligation and Purpose Limitation Obligation, employees who collect personal data could be instructed: (i) to collect only what is reasonable to fulfill its intended purpose(s) (ii) to include consent clauses (including notification of purpose) in registration documents (iii) to put up visible notices at all collection points (both physical and electronic) (iv) to ensure front counter staff are trained in data protection before their first day performing front counter duties; and (v) to maintain a personal data inventory map, personal data flow diagram, and consent registry (see 3.6.6) (b) in connection with the Accuracy Obligation administrative or compliance staff could be instructed: (i) to verify (counter-check) processes to ensure personal data is accurate 83  (ii) to implement procedures for individuals to update their own personal data (iii) to conduct regular personal data update exercises (iv) to be more careful when the source of personal data is a third party (v) to be careful when transcribing hand-written text; and (vi) to train staff who handle personal data on the importance of accuracy when making a decision or disclosing personal data. (c) in connection with the Access and Correction Obligation and the Data Portability Obligation, staff could be instructed: (i) to set up a formal procedure to handle access, correction and data porting requests; (ii) to verify the identity of the requester; (iii) to check the validity of the request and log the date it is received; (iv) while not mandatory, to consider developing a standard request form; and (v) to escalate any issues to the DPO. For further information see the PDPC’s Guide to Handling Access Requests (available at https://www.pdpc.gov.sg/og) (d) in connection with the Retention Limitation Obligation staff could be instructed: (i) to develop retention schedules / policies for personal data (ii) to abide by minimum retention periods required by law and/or by the organisation (iii) to develop procedures for implementing the retention schedules / policies (iv) to communicate the retention schedules / policies to all relevant staff and (v) to develop appropriate / secure disposal procedures (e) in relation to the Transfer Limitation Obligation, staff could be instructed: (i) to ensure a comparable standard of protection is given by law to personal data transferred outside of Singapore; and 84 (ii) if the standard is not comparable consider using contractual clauses or, if the transfer is to a corporate group member, binding corporate rules. 85 6.4 Managing data intermediary risks _________________________________________________________________________ 6.4.1 In summary, in connection with engaging data intermediaries organisations should: (a) conduct appropriate due diligence on proposed data intermediaries to satisfy themselves that the proposed data intermediary is capable of complying with the PDPA; (b) the written contract between an organisation and its data intermediary should contain strong PDPA protection for the organisation because the organisation continues to be responsible for compliance with the PDPA where it arranges for a data intermediary to process that personal date on its behalf; and (c) ensure that it has made reasonable security arrangements to protect personal data and that the collection, use, disclosure by the data intermediary is in compliance with the other PDPA obligations. 6.4.2 At the outset, the senior management of the organisation should have an understanding of the risks involved in outsourcing data processing activities, and establish relevant measures to mitigate the risks. 6.4.3 Organisations that are contemplating engaging vendors to process personal data on their behalf – that is, contemplating engaging vendors that will become data intermediaries under the PDPA – should at the outset of the selection process communicate to potential vendors the organisation’s requirements in connection with PDPA compliance. 6.4.4 Assuming that a potential vendor acknowledges that it will comply with the organisation’s requirements in connection with PDPA compliance, the next step for the organisation is to carry out their due diligence process with the vendor. The objective is for the organisation to determine whether or not the potential vendor is capable of complying with the organisation’s requirements in connection with the PDPA compliance / is capable of complying with the PDPA generally. Here are some examples of checks an organisation can carry out: (a) review the vendor’s personal data protection and information security policies, practices and processes and take steps to make sure that such policies, practices and processes are sufficient to comply with the PDPA, including adequately protecting personal data and that the potential vendor actively implements and enforces them within its business (versus having a ‘paper’ policy that is ignored); (b) conduct a risk assessment to determine the potential vendor’s risk posture in connection with compliance with the PDPA; (c) enquire about what personal data, if any, employees of the potential vendor can access remotely; 86  (d) obtain information about the potential vendor’s security policies and the security of its IT network including by requesting an independent auditor’s report and/or requesting penetration tests and/or vulnerability assessments of its IT systems; and (e) obtain information about the vendor’s data protection practices and capabilities from any other relevant third party sources and conduct random spot-checks on the potential vendor’s operations. 6.4.5 When an organisation has completed its due diligence on a potential vendor’s ability to comply with the PDPA and is satisfied that it is able to do so, the next step is to consider the terms of the processing contract between the organisation and the vendor / data intermediary. These could include the following clauses: (a) clearly specify what the data intermediary may or may not do with personal data provided to it by the organisation – that is, limit the use and disclosure of the personal data to purposes specified by the organisation for which the personal data is being provided to the data intermediary for processing on behalf of the organisation – and specify what, if any, personal data the data intermediary may have access to from remote locations; (b) require the data intermediary to provide the organisation with audit and/or inspection rights; (c) require the data intermediary to provide the organisation with information about any complaints and any potential and actual data breaches and to actively assist the organisation in resolving any complaints and in resolving any issues arising from a potential or actual data breach; (d) specify the data intermediary’s obligations and responsibilities in connection with protecting the personal data provided to it by the organisation or by any third party for the data intermediary to process on behalf of the organisation; (e) set out when and how the personal data is to be disposed off by the data intermediary when the contract ends (either by expiry or earlier termination) or, if earlier, when the data intermediary no longer needs to retain the personal data for the purposes of the contract; and (f) require the data intermediary to indemnify the organisation for any breach or failure to comply with the PDPA by the organisation as a result of an act or omission of the data intermediary. 6.4.6 As part of the engagement, the organisation could also establish and require the data intermediary to comply with standard operating procedures (SOPs) relating to operational procedures and reports. Specifically, such reporting include regular management reports on a periodic basis and ad-hoc incident reports. For more information see: 87 (a) PDPC’s Guide to Managing Data Intermediaries (available at https://www.pdpc.gov.sg/og) (b) PDPC’s Guide on Data Protection Clauses for Agreements Relating to the Processing of Personal Data (available at https://www.pdpc.gov.sg/og) (c) PDPC’s Guide to Disposal of Personal Data on Physical Medium (available at https://www.pdpc.gov.sg/og) (d) PDPC’s Guide to Managing Data Breaches 2.0 (available at https://www.pdpc.gov.sg/og) 88 6.5 Managing risks relating to data sharing _________________________________________________________________________ 6.5.1 In addition to sharing personal data between various parts / departments in a single organisation, an organisation might decide to share personal data with: (a) a data intermediary so that it can process the personal data on behalf of the organisation; (b) another organisation in the same corporate group – for example, where group members use a shared HR department or subsidiaries are required to provide the HQ entity with information about employees of the subsidiary; and (c) a third party organisation which is a business partner of some kind or for some purposes. In all cases, the organisation must manage the risks of failing to comply with the PDPA that arise due to that data sharing. See the PDPC’s Guide to Data Sharing (available at https://www.pdpc.gov.sg/og). 6.5.2 Under the PDPA, the rules about sharing personal data may be summarised as follows: (a) to share personal data between departments of the same organisation or among organisations in the same corporate group: personal data may be shared within or between organisation for purposes which the individual had consented to or through avenues such as exceptions and exemptions (e.g. pursuant to the new Business Improvement Purposes Exception for related corporations), where applicable; (b) Deemed consent by contractual necessity for the sharing of personal data with another organisation for conclusion of contract between the individual and the organisation: where an individual provides personal data to an organisation with a view to the individual entering into a contract with the organisation, the individual is deemed to consent to the following where reasonably necessary for the conclusion of the contract between the individual and the organisation: (i) the disclosure of that personal data by the organisation to another organisation; (ii) the collection and use of that personal data by the other organisation; and (iii) the subsequent disclosure of that personal by the other organisation in question to further organisations; (c) to share personal data with a data intermediary pursuant to a written contract: (i) express consent of the relevant individual is not required; 89  (ii) the transfer is governed by the contract between the disclosing organisation and the data intermediary and the data intermediary processes the personal data in accordance with the disclosing organisation’s instructions and should not use it for its, the data intermediary’s, own purpose; and (d) to share personal data with organisations other than data intermediaries (e.g., through data collaboration arrangements involving both private sector organisation and public agencies): this is typically done through avenues such as consent of the individual, exceptions to consent as set out in the First Schedule to the PDPA (exceptions to the consent requirement which apply collectively to the collection, use and disclosure of personal data) and the Second Schedule to the PDPA (exceptions to the consent requirement which apply separately to the collection, use or disclosure of personal data) For further guidance on data sharing arrangements please refer to: PDPC | Data Sharing Arrangements. 6.5.3 Typically, the PDPA considerations that are relevant to any plan to share personal data include: (a) consent: whether the relevant individual must expressly consent to the data sharing or whether the disclosure to another organisation falls within one of the exceptions to consent in the First or Second Schedules to the PDPA; (b) notification: where consent is required, whether the organisation needs to notify the individual that their personal data will be shared and with what organisation / type of organisation, purpose of sharing and whether the organisation will share it further; (c) protection: by contract: (i) limit the access to the shared data only to those of the recipient’s employees on a ‘need to know’ basis and and require them to be bound by confidentiality agreements; and (ii) specify how the personal data will be shared – how the organisation will deliver or transmit it to the recipient – and how the recipient must protect it during any re-transfer as well as when it is in the possession of the recipient, paying particular attention to any sensitive personal data that is being shared. 6.5.4 Before agreeing to share personal data with another organisation, an organisation should make sure that the format of the data is compatible with the systems of both the disclosing organisation and the recipient. In addition, the disclosing organisation should: (a) be clear about: 90  (i) what the data sharing is intended to achieve for both the disclosing organisation and the recipient organisation – that is, have a clear set of objectives; and (ii) whether it will be an ongoing arrangement or, for example, something that will take place in response to particular defined events and, if it is ongoing, the events that should trigger a review of the data sharing arrangement; (b) consider whether the objectives of the data sharing could be achieved without sharing personal data, including by anonymising the personal data – it is not appropriate to share personal data where the objective of doing so could be achieved without identifying the individual; (c) critically consider what personal data needs to be shared to achieve that set of objectives and share no more personal data than is necessary to do so – do not take a short cut and simply share entire files when there is no need to do so and some personal data in the file would be irrelevant to the purpose for which the data is being shared; (d) in connection with the Accuracy Obligation: (i) ensure that the personal data is accurate and complete before sharing it with another organisation; and (ii) devise a process for updating the recipient organisation whenever the share data is changed by any reason, including as a result of the relevant individual’s right to correct personal data in the possession or under the control of the organisation; (e) train its staff so that they know who has the authority to share personal data, what personal data may be shared, with whom it may be shared and under what circumstances it may be shared; (f) identify the risks posed by the data sharing, including whether any individual is likely to be damaged by it and whether any individual is likely to object; (g) by contract, limit the access to the shared data only to those of the recipient’s employees who have a ‘need to know’ and require them to be bound by confidentiality agreements; (h) be clear about how the personal data will be shared, how it will be delivered or transmitted to the recipient – agree with the recipient the rules that will apply to protect the personal data during transfer as well as when it is in the possession of the recipient; (i) by contract, agree on appropriate retention periods and deletion arrangements for both the disclosing organisation and the recipient organisation; (j) periodically reconsider: 91 (i) the objectives of the data sharing, whether it is achieving them and what changes, if any, should be made to the data sharing arrangement to improve its effectiveness in achieving its objectives; and (ii) whether the risks posed by the data sharing have changed as well as whether the safeguards implemented for the data sharing continue to match the risks and, if not, adjust them as necessary and generally review a data sharing arrangement in accordance with the organisation’s data governance frameworks. 92 6.6 Managing risks relating to outsourcing IT services _________________________________________________________________________ 6.6.1 It is not uncommon for organisations, especially small and medium enterprises (SMEs), to outsource their IT needs to IT service providers. In any such case, both the organisation and the IT service provider are responsible for protecting the personal data handled by the organisation’s IT system when it is outsourced. The solutions provided by the IT service provider may be: (a) bespoke: written or adapted for a specific user or purpose / designed according to an organisation’s specific needs; or (b) ready-made / off-the-shelf and not able to be changed, although it can be customised to some extent by changing configuration settings – this includes commercial off-the-shelf software, social media platforms such as Facebook and Google+ and website or blog creation systems such as WordPress, Joomla and Tumblr. 6.6.2 Some ready-made software allows add-on capabilities through plug-ins. Open source software is also ready-made. Organisations may be able to modify the source code for open source software, but in general it is quite common for open source software to be used in its original form or with minimal modification. 6.6.3 Organisations need to understand the capabilities, features and limitations of ready- made software and find out how the software collects, protects, uses and discloses personal data before using it, including any plug-ins. If they do not, organisations risk no knowing how such systems collect, protect, use and disclose personal data. 6.6.4 Unless an IT system is entirely developed from scratch and deployed under full control of the organisation, it likely makes use of ready-made components or services to some extent. While such ready-made components or services cannot be completely controlled by an organisation, organisations should always ensure sufficient protection for the parts for which they retain control. This is analogous to the scenario where an organisation leases office space. The organisation first chooses an appropriate office where robust building security is provided by the building management. However, the organisation is still responsible for the security of its own office unit. The organisation may install a lock at its office entrance, an alarm system, CCTV, a safe, etc. 6.6.5 Organisations should ensure that their employees are provided with the appropriate training to ensure proper usage of the software deployed by the organisation. 6.6.6 In summary, in connection with IT service providers an organisation should at least: (a) for bespoke solutions: (i) ensure that the IT service provider is aware that the organisation intends to use their services to handle personal data so that the design of the system can take that fact into account and provide sufficient 93  protection to the personal data to enable the organisation to comply with the PDPA; and (ii) spell out the organisation’s security requirements in the contract(s) between the organisation and the vendor(s); and (b) for ready-made solutions: (i) acquire a clear understanding of the solution; (ii) select solutions that offer sufficient protection to personal data; (iii) select solutions that match the organisation’s requirements well; (iv) understand the features and limitations of the solution, including plug- ins, processing personal data, before putting it into use; and (v) provide protection for the parts of the IT system or personal data that are still under direct contract. 6.6.7 Setting up a website, particularly with more complex functions such as online ordering, membership management and event management, requires IT expertise. As not all organisations have the resources to develop such websites by themselves, they may decide to outsource the development and maintenance of the website. This would entail the engagement of one or more IT vendors to: (a) provide the design, layout and artwork / graphics for the website; (b) develop – that is, program – the website to perform the intended functions; (c) host the website so that it is accessible on the internet; (d) perform administrative tasks, such as managing user accounts, and/or (e) maintain the website by updating the design, layout, graphics and programming when required, with each vendor installing security features relevant to their particular responsibility for development of the website to ensure security requirements are met in a way that is sufficient to enable the organisation to comply with the Protection Obligation under the PDPA. 6.6.8 Security is an important component in each of the activities in 6.6.7 and organisations should require their IT vendors to include it in each of them by including security requirements in their contractual terms: the contract should state clearly the responsibilities of the IT vendor with respect to the PDPA – for example: (a) requiring an IT vendor to consider how personal data should be handled as part of the design and layout of the website; 94  (b) planning and developing the website in a way that ensures that it does not contain any web application vulnerabilities that could expose the personal data of individuals collected, stored or accessed via the website through the Internet; (c) requiring the IT vendor who hosts the organisation’s website to ensure that the servers and networks are securely configured and adequately protected against unauthorised access; and (d) requiring the IT vendor who provides administrative support for the website and/or maintenance of the website to ensure that any changes they make to the website do not contain vulnerabilities that could expose the personal data. 6.6.9 Organisations and IT vendors may choose to use ready-made software and/or software components provided by third parties who are not involved with the development of the website. While this may speed up the programming of the organisation’s website, organisations and their IT vendors should have a clear understanding of how such ready-made software and/or software components handle personal data and how it must be configured, before using it for the organisation’s website. For additional information on the use of ready-made software and/or software components see the ‘ICT Outsourcing’ section in the PDPC’s Guide to Securing Personal Data in Electronic Medium (available at https://www.pdpc.gov.sg/og); 6.6.10 When an organisation is negotiating with a vendor that will do any activities connected with a website for the organisation (see 6.6.7), the contract should make clear the purpose for which the IT vendor is engaged and the organisation should include among the vendor’s responsibilities, as the case may require: (a) considering how personal data should be handled by the website as part of the design and layout of the website; (b) planning and developing the website in a way that ensures that it does not contain any web application vulnerabilities that could expose the personal data of individuals collected, stored or accessed via the website through the Internet; (c) requiring that IT vendors who provide hosting for the website should ensure that the servers and networks are securely configured and adequately protected against unauthorised access; (d) when engaging IT vendors to provide maintenance and/or administrative support for the website, requiring that any changes they make to the website do not contain vulnerabilities that could expose personal data; (e) ensuring that personal data is not disclosed to unauthorised parties by the vendor’s personnel or sub-contractors; (f) having processes for secure handling of personal data during the development of the website and especially during maintenance phases; 95  (g) implementing confidentiality agreements for its personnel and sub-contractors; and (h) implementing technical and/or non technical measures to ensure consistent enforcement of confidentiality requirements and prevent personal data from being exposed accidentally or otherwise , including considering encryption and/or data masking measures. See the PDPC’s Guide on Building Websites for SMEs (available at https://www.pdpc.gov.sg/og) 6.6.11 When considering an organisation’s obligation to comply with the Protection Obligation under the PDPA and the manner in which it may do so, security arrangements for the organisation’s website should not be limited to technical solutions agreed with an IT vendor. Organisations should also put in place policies and processes to protect the personal data collected, stored or accessed through the website. There should be processes where vendors have to get approval from the organisation to make changes to the website. 6.6.12 Suggested policies and processes for organisations and their IT vendors (if any) to consider for implementation from a security perspective in order for the organisation to comply with the Protection Obligation, the Retention Limitation Obligation and the Data Breach Notification Obligation under the PDPA are: (a) organisations should conduct a risk assessment of the website, require that their IT vendor(s) conduct a risk assessment or require that their IT vendor(s) assist the organisation in its risk assessment of the website: (i) a risk assessment will help to identify the security risks that the website faces and to identify the possible impacts to the organisation if personal data is exposed; (ii) based on the risk assessment the organisation, with the help of their IT vendors (if any), will be able to better select the most appropriate security measures for the website; and (iii) the risk assessment and security arrangements should be reviewed and updated on a regular basis; (b) organisations should ensure, or require their IT vendor(s) to ensure, that the software and hardware components of the organisation’s website are properly configured to prevent unauthorised access – this includes reviewing operating systems, checking if appropriate antivirus / anti-malware software are in place and setting firewall rules to only allow authorised traffic; (c) organisations should ensure, or require their IT vendor(s) to ensure, that the configuration of each software and hardware component of the organisation’s website is fully documented, kept up-to-date and reviewed regularly; 96  (d) organisations should ensure, or require their IT vendor(s) to ensure, that they have a plan for testing and applying patches and updates for the website’s software and hardware components – this includes having a process and a person responsible to monitor new patches and updates that become available; (e) testing a website for security vulnerabilities is an important aspect of ensuring the security of a website so organisations should ensure that: (i) penetration testing and/or vulnerability assessments are conducted prior to making the website available to the public, as well as on a periodical basis (for example, annually); and (ii) any discovered vulnerabilities are reviewed and promptly fixed to prevent data breaches. Where an organisation has outsourced the development of its website, it should require the IT vendor(s) to conduct the above security testing. As a baseline, organisations may wish to consider using the Open Web Application Security Project (OWASP) Testing Guide and the OWASP Application Security Verification Standard (ASVS) (both available at https://www.owasp.org) to verify that security requirements for the website have been met; (f) organisations and their IT vendors (if any) should keep track of where the collected personal data is stored, should impose a limit on how long it is kept, and should regularly review their need to continue storing the personal data – if the personal data is no longer required by the organisation, the organisation and their IT vendors (if any) should then ensure that the personal data is anonymised or disposed of in such a way that it cannot be recovered; (g) organisations and their IT vendors (if any) should clarify their respective roles on incident management and plan their potential actions in the event that the website’s security is compromised: (i) in the event of a potential security incident, the IT vendor should notify the organisation and assist the organisation in any investigation and in fulfilling the organisation’s reporting obligations under law; (ii) an incident response plan that is prepared in advance will be useful for handling security incidents (see 9) to ensure that they are immediately dealt with to prevent personal data from being exposed; and (iii) the incident management plan should cover business continuity requirements such as back-up, restoration and (where applicable), preservation of evidence for investigation. 6.6.13 Organisations might also require that their IT vendor(s) propose more detailed IT policies based on the suggestions in 6.6.12. 97 6.6.14 For more guidance in relation to outsourcing, especially where the IT vendor is also a data intermediary, see PDPC’s Guide to Managing Data Intermediaries (available at https://www.pdpc.gov.sg/og). 98 6.7 Managing risks relating to existing ICT systems and the development of new ICT systems _________________________________________________________________________ 6.7.1 When designing and building information and communications technology (ICT) systems, the organisation’s IT project managers, system architects and software developers involved insystem or software development work may consider applying Data Protection by Design (DPbD). 6.7.2 DPbD is an approach where data protection measures are considered and built into ICT systems that involve the processing of personal data as they are being developed. By taking into consideration data protection principles from the start, organisations will be able to build systems to better safeguard personal data and create a culture of good data management practices. 6.7.3 Some of good DPbD practices for ICT projects include: (a) conducting a DPIA when the preliminary design of a new ICT system has been established (see Section 8 below on DPIA); (b) minimise collection of personal data (e.g. by consider not collecting metadata, collecting personal data only when needed, and through user input instead of automatic collection); (c) implementing access controls (e.g. by implementing access controls at the applications, avoid creating backdoors bypassing access control, and implementing one-time passwords or multi-factor authentification where required); (d) factoring in adequate resources to conduct relevant security testing and to ensure that the data protection measures operate as intended (e.g. by conducting code review, vulnerability assessments); (e) housekeeping of personal data in ICT systems (e.g. removing temporary files containing personal data, and being careful with data migration files); and (f) protecting personal data in its exported form (e.g. by encrypting exported data, communicating encryption key separately, and applying anonymisation techniques). 6.7.4 For existing systems, organisations may consider going through the following steps: 99  (a) Rethink: thoroughly reviewing the existing system, considering what personal data is being collected and whether the collection is completely necessary, assessing risk, etc.; (b) Redesign: implementing relevant DPbD good practices to better protect personal data and reduce the risks identified earlier; and (c) Revive: starting afresh with the data protection-enhanced system. 6.7.5 For more information on DPbD for ICT Systems, see Guide to Data Protection by Design for ICT Systems (available at: https://www.pdpc.gov.sg/og). 100 6.8 Managing risks to personal data in the electronic medium _________________________________________________________________________ 6.8.1 To manage risks to personal data in electronic medium, the organisation: (a) needs to understand and implement sufficient technical measures to protect personal data in electronic medium (or ‘electronic personal data’); (b) implement good practices that organisations should undertake to protect electronic personal data; and (c) consider adopting enhanced practices to further improve protection of electronic personal data; 6.8.2 However, there is no ‘one-size-fits-all’ solution for organisations. Therefore, each organisation should adopt security measures that are reasonable and appropriate for that organisation’s circumstances. Some factors that organisations can take into account when deciding on the type of security measures to adopt include: (a) the type of personal data held by the organisation; (b) the risk and impact to the individual should such personal data be accessed and used by unauthorised persons; (c) the form of the personal data (that is, physical or electronic) in the organisation’s possession or under its control; and (d) applicable industry or professional requirements. 6.8.3 The PDPC has published a Guide to Securing Personal Data in Electronic Medium (available at https://www.pdpc.gov.sg/og). The Guide includes a Consolidated Checklist of Good Practices and a Consolidated Checklist of Enhanced Practices. The Guide is regularly updated and DPOs should always refer to the latest version of the Guide. 101 6.9 Managing risks connected with cloud computing _________________________________________________________________________ 6.9.1 Cloud computing is an on-demand service model for IT provisioning that is often based on virtualisation and distributed computing technologies. Virtualisation is generally accomplished by dividing a piece of hardware into two or more ‘segments’. Each segment operates as its own independent environment. For example, server virtualisation partitions a single server into a number of smaller virtual servers; storage virtualisation amalgamates a number of storage devices into a single, cohesive storage unit. Essentially, virtualisation makes computing environments independent of physical infrastructure. Computing technologies are described as distributed when something is shared among multiple systems that may also be in different locations. 6.9.2 There are various cloud models, including: (a) software as a service (SaaS): a software distribution model in which a third party provider hosts applications and makes them available to customers over the internet – for example, SharePoint Online, Office 365; (b) platform as a service (PaaS): services that provide computing platforms that typically include an operating system, a programming language execution environment, database, web-server, etc. – for example, Windows Azure, SQL; and (c) infrastructure as a service (IaaS): a computing infrastructure, provided and managed over the Internet. Depending on the cloud service model, an organisation accepts that it relinquishes varying levels of control over personal data. It is generally considered that organisations have the least control when they use SaaS. The degree of control increases when they use PaaS and increases further when they use IaaS. 6.9.3 There are various cloud deployment models, such as: (a) private clouds: the cloud customer is the sole user of the cloud service – the underlying hardware may be managed and maintained by a cloud provider under an outsourcing contract and access to the cloud may be restricted to a local or wide area network; (b) public clouds: the infrastructure, platform or software is managed by the cloud provider and made available to the general public – users are known as ‘cloud customers’ or ‘cloud end-users’ and access to the cloud service is likely to be over the public internet; (c) community clouds: a group of cloud customers access the resources of the same cloud service – typically, the cloud customers will share specific requirements, such as a need for legal compliance or high security which the cloud service provides and access to the cloud service may be restricted to a wide area network; and 102  (d) hybrid clouds: this term describes a combination of private, community and public clouds – a cloud customer will segregate data and services across different cloud services, with access between them restricted depending on the type of data they contain. Depending on the cloud deployment model, an organisation accepts that it relinquishes varying levels of control over personal data. It is generally considered that organisations have the least control when they use a public cloud, that higher levels of control may be achieved with community and hybrid clouds and that private clouds offer the most control 6.9.4 The design and operations of cloud computing differ to some extent from non-cloud (also called ‘on premise’) IT systems. Organisations that adopt cloud services for the management of personal data need to be aware of the security and compliance challenges that are unique to cloud services. They need to consider the controls / rules that they should implement to manage to treat those risks. 6.9.5 Where an organisation is not able to get a cloud service provider to customise a service for the organisation, the organisation must decide if the security measures put in place by that cloud service provider provides reasonable security for the personal data so that the organisation can be confident that it will comply with the protection obligation under the PDPA. Many cloud service providers publish a list of the security measures that they offer. Organisations can use such lists to make a decision on whether the level of protection is sufficient for the personal data that the organisation would store in the cloud. 6.9.6 Organisations may refer to existing standards, such as the Multi-Tier Cloud Security (MTCS) (8) and ISO 27018(9) for additional guidance. 6.9.7 The Multi-Tier Cloud Security Standard for Singapore (MTCS SS) (see https://www.imda.gov.sg/industry-development/infrastructure/ict-standards-and- frameworks/mtcs-certification-scheme and https://www.imda.gov.sg/industry- development/infrastructure/ict-standards-and-frameworks/mtcs-certification- scheme/multi-tier-cloud-security-certified-cloud-services) has a self-disclosure requirement for Cloud Service Providers (CSPs) covering areas such as data retention, data sovereignty, data portability, liability, availability, business continuity, disaster recovery, incident management and problem management. Certified CSPs are able to spell out the levels of security that they can offer to their users. Organisations that use cloud computing services are able to use the MTCS SS to better understand and assess the cloud security they require. 6.9.8 Organisations can also refer to the chapter on Cloud Computing in PDPC’s Guide to Securing Personal Data in Electronic Medium (available at https://www.pdpc.gov.sg/og). 6.9.9 A cloud service provider can meet the security demands of its cloud customers and potential cloud customers by, for example: 103  (a) engaging and independent third party to conduct a security audit of its services and then making the report available to its cloud customers and potential cloud customers; and (b) providing its cloud customers with regular updates on the security measures it has in place. 6.9.10 If an organisation decides to use cloud computing services if may address its PDPA compliance risks in various ways including: (a) using encryption to ensure only authorised parties with the correct ‘key’ can access the personal data; (b) securing data ‘in transit’ between endpoints and within the cloud service (including data transferred between data centres that are geographically apart) to protect that data from interception; (c) encrypting data ‘at rest’ (that is, when it is stored within the cloud service) if it is sensitive personal data; (d) implementing adequate measures to prevent unauthorised access to data that is available to the organisation’s employees from any location; (e) if the cloud service offers an authentication system (for example, if it uses a username and password system): (i) implementing a process to create, and requiring each of the organisation’s employees to use, their own accounts; and (ii) implementing a process to update, suspend and delete user accounts when employees forget or loose their log in credential or they are stolen the employee leaves the organisation; (f) ensuring the cloud service provider deletes all copies of personal data that the organisation has stored in the cloud within the organisation’s retention and deletion schedule / policies (including deleting multiple copes of data stored in multiple locations and including back-ups); (g) ensuring the organisation understand what will happen to personal data it has stored in the cloud if the organisation decides to withdraw from the cloud service; (h) ensuring there is a clear policy implemented by the cloud provider unilaterally or agreed between the organisation and the cloud provider to specify the circumstances in which the cloud provider may access the personal data it processes for the organisation – the policy should include an audit process that will alert the organisation if unauthorised access, disclosure, deletion or modification occurs; and (i) ensuring that under contractual arrangements the cloud provider: 104  (i) must not process personal data for the purposes other than those specified by the organisation; and (ii) must not process any personal data stored in the cloud by the organisation for the cloud provider’s own advertising purposes, unless such processing has been authorised by the organisation after the organisation has obtained any necessary consent from the relevant individuals in connection with the personal data about them. 6.9.11 Where a single cloud provider acts as a data processor for many cloud customers / organisation and, in turn, may support a large number of cloud users / employees of the organisation on the same systems the organisation should ensure that, for example: (a) the cloud provider has a robust set of safeguards in place to protect against the possibility of one cloud customer gaining access to personal data held by another cloud customer; and (b) the cloud provider ensures that the activities of one cloud customer do not impact the activities of another cloud customer. 6.9.12 If by engaging the cloud provider or throughout the course of the engagement of the cloud provider, overseas transfers of personal data is contemplated, the organisation is responsible for complying with the Transfer Limitation Obligation. This is regardless of whether the cloud provider is located in Singapore or overseas. Accordingly, the organisation could ensure that the cloud provider it uses only transfers data to locations with comparable data protection regimes, or has legally enforceable obligations to ensure a comparable standard of protection for the transferred personal data. 6.9.13 In this regard, ideally the contract should specify where the cloud provider may transfer personal data to. However, if this is left to the discretion of the cloud provider, the organisation should ensure that (a) the cloud provider based in Singapore is certified or accredited as meeting relevant industry standards, and (b) the cloud provider provides assurances that all the data centres or sub-processors in overseas locations that the personal data is transferred to comply with these standards. 6.9.14 In summary, the contract between the organisation and the cloud provider should include controls and clauses covering the following subjects in connection with the cloud provider: (a) the information security practices it has adopted; (b) how it protects personal data; (c) how it controls access to personal data by, for example, employees of the organisation; (d) retention and deletion of personal data; 105 (e) the purposes for which its, the cloud provider’s, employees may have access to the organisation’s personal data how it controls such access; (f) restrictions on the cloud provider processing personal data beyond the processing it does on behalf of, and in accordance with instructions from, the organisation; (g) safeguards in a multi-tenancy environment (see 6.8.11); and (h) if overseas transfer of personal data is contemplated (e.g. the cloud servers are overseas), the contract should, for instance, ensure that personal data may only be transferred to overseas locations with comparable data protection laws, or that the recipients (e.g. data centres or sub-processors) in these locations are legally bound by similar contractual standards. 106 6.10 Managing risks using anonymisation _________________________________________________________________________ 6.10.1 Under the Retention Limitation Obligation an organisation must cease to retain documents containing personal data as soon as it is reasonable to assume that the purpose for which that personal data was collected is no longer being served by retaining it if retention is no longer necessary for legal or business purposes. However, under the Retention Limitation Obligation an organisation may instead ‘remove the means by which the personal data can be associated with particular individuals’ – that is, by anonymisation. 6.10.2 ‘Anonymisation’ refers to the process of removing identifying information, such that the remaining data does not identify and particular individual. Anonymisation is a useful technique that enables organisations to retain and use what would otherwise be personal data about individuals when such use does not require the organisation to be able to identify them. 6.10.3 Anonymisation enables organisations to do, for example, trend analysis of historical data or statistical analysis of market research data. Organisations can focus on various data values (such as, height, weight, user preferences) when such analysis does not depend on the identity of the individuals (such as, their NRIC numbers, their name and/or their address). If an organisation is able to mask the identity of an individual in CCTV footage, that too can amount to anonymisation. 6.10.4 There are various techniques that an organisation can use to anonymise personal data. Recapping Module A of this programme, they include: (a) attribute suppression: the removal of an entire part of data (also referred to as “column” in databases and spreadsheets) in a dataset, when such an attribute is not required or cannot otherwise be anonymised; (b) record suppression: the removal of an entire record in a dataset, to remove outlier records which are unique or do not meet other criteria; (c) character masking: the change of the characters of a data value, e.g. by using a constant symbol (e.g. “*” or “x”), when the data value is a string of characters and hiding part of it is sufficient to provide the extent of anonymity required; (d) pseudonymisation: the replacement of identifying data with made up values, when data values need to be uniquely distinguished and where no character or any other implied information of the original attribute shall be kept; (e) generalisation: a deliberate reduction in the precision of data for values that can be generalised and still be useful for the intended purpose; and (f) swapping: rearrange data in the dataset such that the individual attribute values are still represented in the dataset, but generally, do not correspond to the original records, when subsequent analysis only needs to look at aggregated data, or analysis is at the intra-attribute level. 107 6.10.5 The term ‘textual personal data’ refer to text, numbers, dates, etc. that are alpha- numeric data already in digital form. Other techniques that an organisation can use to anonymise textual personal data include: (a) suppression of: (i) a record: an entire record is removed for the dataset; or (ii) an attribute: an entire part of a record (such as an entire column in a database or a spreadsheet) is removed; (b) character masking: the characters of a data value are changed, for example by using a constant symbol such as ‘*’ or ‘x’ – masking is typically partial in the sense that it is applied only to some characters in the attribute; (c) pseudonymisation: personal identifiers are replaced with other references or made up values; (d) generalisation / recoding: the precision of the data is reduced deliberately – for example, by converting the age of individuals into an age range or converting a precise location into a general or less precise location; (e) swapping / shuffling / permutation: data in a dataset is rearrange such that the individual attribute values are still represented in the dataset, but they generally do not correspond to the original records; (f) data perturbation: the values from the original dataset are modified to be slightly different; (g) synthetic data: synthetic datasets are generated directly and separately from the original data, instead of modifying the original dataset; and (h) data aggregation: a dataset is converted from being a list of records to summarised values. For more information see the PDPC’s Guide to Basic Data Anonymisation Techniques (available at https://www.pdpc.gov.sg/og), and PDPC’s Advisory Guidelines on the PDPA for Selected Topics – Anonymisation (available at https://www.pdpc.gov.sg/ag). 6.10.6 Personal data in documents and reports can be anonymised by: (a) redacting: that is, removing, individual’s names from documents; and (b) changing details in a report, such as removing precise place names and/or precise dates. 6.10.7 Streaming personal data is personal data in, for example, video footage and photographs, and audio recordings. It can be anonymised by: (a) blurring video footage and photographs to disguise faces; and 108  (b) electronically disguising or re-recording audio material. 6.10.8 ‘Re-identification’ or ‘de-anonymisation’ is the process by which anonymised data is combined with other information such that an individual can be identified or re- identified. There are two main methods of re-identification: (a) someone takes personal data that they already hold and searches an anonymised dataset for a match; and (b) someone takes a record from an anonymised dataset and seeks a match in publicly available information. 6.10.9 As computer power and the public availability of data increase, so will the risk of re- identification. In the era of ‘Big Data’ and powerful computers, it is relatively easy today to match and merge datasets from publicly available data to identify and individual from anonymised data. The risk of one anonymised dataset being matched with another to produce personal data can be reduced by using sampling techniques. Only parts of datasets, rather than whole datasets are released, making direct linkage more difficult. 6.10.10 The ‘Motivated Intruder Test’ is a general test for assessing the risks of re- identification and the robustness of anonymisation. It starts without any prior knowledge to identify the individual from the anonymised data. It considers whether individuals can be re-identified from anonymised data by someone who is motivated, reasonably competent, has access to standard resources (for example, the Internet and published information such as public directories) and employs standard investigative techniques (for example, making enquiries of people who may have additional knowledge of the identity of the individual / data subject. 6.10.11 The PDPC’s Advisory Guidelines on the PDPA for Selected Topics – Anonymisation (available at https://www.pdpc.gov.sg/ag) provides details of the ‘Motivated Intruder Test’ at paragraphs 3.26 to 3.28. 6.10.12 It is good practice to re-assess the risk of re-identification periodically using the Motivated Intruder Test. Carrying out the Motivated Intruder Test in practice might include: (a) doing a web search to discover whether a combination of birth date and postcode data can be used to reveal a particular individual’s identity; (b) searching the archives of newspapers to see whether it is possible to associate a victim’s name with crime map data; (c) using social networking to see if it is possible to link anonymised data to a user’s profile; and/or (d) using the electoral register and local library resources to try to link anonymised data to someone’s identity. 109 6.11 Managing risks to personal data in the physical medium _________________________________________________________________________ 6.11.1 The data protection obligations under the PDPA (other than the data portability obligation) apply to both electronic records and records captured in a physical medium. ‘Physical medium’ refers to: (a) paper, mainly; and (b) but also other read-only storage media, such as CDs and DVDs, but does not include re-writeable media, such as hard-disks and USB memory sticks because they allow for nearly unlimited over-writing of data so that personal data may be disposed of from these types of media without the need to dispose of the medium itself. 6.11.2 The PDPC has published a Guide to Disposal of Personal Data in Physical Medium (available at https://www.pdpc.gov.sg/og). The Guide includes a Consolidated Checklist of Good Practices. It is annexed to this Participant’s Guide. 6.11.3 While recognising that there is no ‘one-size-fits-all’ solution, consider the following with regards to disposal of personal data in physical form: (a) ensure documented policies and corresponding procedures that organisations should put in place to protect personal data, including where external parties may be given access to it) by providing a summary of information, issues and best practices for disposal of personal data; and (b) includes schedules that define the respective retention limitations for personal data in the possession or under the control of an organisation (for example, how long organisations should keep records), but do not cover the details on such schedules – but notes that organisations need to be aware that untimely or unauthorised disposal of personal data are important factors to consider beyond the methods applied during disposal because they pose additional risks for the organisation. 6.11.4 The PDPC’s Guide to Disposal of Personal Data in Physical Medium focuses on the aspect of destruction, mainly addressed paper (that is, documents, photos, posters, etc.) storing personal data. Destruction makes the medium non-reusable. While some electronic media, such as USB sticks and hard-disks may allow for sanitisation to some degree (basically, by over-writing the data), other media such as write-once or read- only CDs and DVDs do not support over-writing and therefore require physical destruction. 6.11.5 Similar principles as described in this Guide for paper medium may apply to electronic media that do not support over-writing, be it because they do not support sanitisation or because physical destruction in addition to ‘logical’ or ‘electronic’ sanitisation is needed. As such, there are two methods for the disposal of personal data, noting that 110  the effect of the disposal method must be such that the data cannot be recovered (either partially or fully) regardless of whichever method is used: (a) destroy the medium carrying the data – this renders the data inaccessible and is generally applied to non-electronic, single-use storage media; or (b) dispose of only the data itself – where it is possible to securely erase the data without destroyed the storage medium, but specialised software or tools may be needed – standalone data erasure is generally associated with electronic media. 6.11.6 Organisations should not take disposal lightly. It needs to be well-managed and controlled throughout the entire data lifecycle. The Protection Obligation under the PDPA does not end with personal data simply being discarded in the (physical or electronic) trash bin and incomplete disposal can lead to data breaches, such as: (a) deleted electronic files or improperly shredded paper may be restored (in full or partially); and (b) uncontrolled disposal of paper without destruction may lead to recovery of documents through ‘dumpster diving’ (for example, sifting through physical waste or recycling containers for items that have been discarded but are still of value or covered by regulation). 6.11.7 Even for media where sanitisation is possible, due to technological issues and advances in sophistication of hackers and attack methods, the (additional) destruction of the media itself may be required where such a medium holds more sensitive or high volume of personal data. 6.11.8 For personal data stored on physical media and in paper form, organisations should ensure proper disposal of the documents that are no longer needed through shredding or other appropriate means. For personal data stored on paper, proper disposal or destruction usually refers to putting the paper through one or more of the following processes: (a) shredding: cuts paper in a way that makes it reasonably difficult, or even impossible, to reassemble the pieces in order to reconstruct (a substantial part of) the information, but allows for the paper to be recycled as long as the pieces are not too small; or (b) pulping: paper is mixed with water and chemicals to break down the paper fibres before it is processed into recycled paper. 111 6.12 Managing risks to data in transit / accidental disclosure _________________________________________________________________________ 6.12.1 One of the ways that an organisation needs to protect personal data is by preventing it being sent off to the wrong recipient(s). This has the following aspects. 6.12.2 When personal data will be sent outside the organisation, the organisation must implement procedures to ensure that the destination information is correct. This includes: (a) where the organisation will process documents or communications containing personal data automatically (for example, merging content or populating fields from various sources): (i) ensuring the accuracy and reliability of the automated processing, implemented by checking these systems and processes at the outset and regularly; and (ii) where the personal data is sensitive, considering incorporating additional checking mechanisms to cater for unexpected situations, to ensure that no error arises from the automated processing: (b) establishing procedures to include additional checks following the processing, printing and sorting of documents to ensure that the destination information is correct and matches that of the intended recipient(s) prior to sending; (c) performing regular housekeeping of auto-complete email list and double- checking recipients’ email addresses or documents containing personal data and/or sensitive date; and (d) when sending mass emails on a regular basis, using mailing lists where possible instead of typing out each email address manually, which may be prone to inaccuracy. 6.12.3 When personal data will be sent outside the organisation, the organisation must implement procedures to ensure that the personal data that is sent is correct. This may be done by: (a) establishing procedures to perform additional checks to ensure the right document containing personal data, or the right personal data contained in the document, is sent; and (b) when sending emails, double-checking that the right files (that is, the files containing the correct personal data) are attached in the email. 112 6.12.4 When personal data will be sent outside the organisation, the organisation must implement procedures to ensure that only the relevant personal data is disclosed to the recipients. This includes: (a) establishing a policy for sending compiled sets of personal data of different individuals (for example, in spreadsheets); (b) ensuring there is consent from individuals to send their personal data to recipients other than themselves; and (c) ensuring all emails sent externally to a group of recipients have the receipients’ email addressed placed in the BCC line, not to the ‘To’ line of the CC line. 6.12.5 The organisation should ensure correct usage of software, including: (a) ensuring that staff are trained and familiar with the software used to process and send out documents containing personal data – staff should also be trained to spot any mismatching data after sorting has been carried out; and (b) establishing clear, step-by-step procedures when using software to send out emails, including ensuring that the software is configured correctly and updated regularly, and that the correct email addresses are used. 6.12.6 The organisation should minimise the impact of accidental disclosure, including by: (a) establishing an email policy for documents containing personal data to be secured with passwords when sending to internal as well as external recipients; (b) including a notice in all emails, faxes and letters to warn recipients against unauthorised use, retention or disclosure of personal data and to inform the recipients to delete and notify the organisation immediately of any personal data sent to them in error; and (c) ensuring that new and existing staff receive regular training so that they are well apprised and updated on the proper procedures for processing and sending personal data – the organisation should also regularly remind staff to perform the necessary checks and not become complacent in relying solely on automated systems and staff should not just ‘click through’ any alerts, but diligently verify the alert information. 6.12.7 The organisation should ensure that the organisation (data intermediary) to which it is outsourcing the processing and sending of personal data: (a) has in place appropriate personal data protection policies and procedures for the work that is being outsourced; (b) has breach management protocols in place, including protocols to report any data breaches to your organisation; 113  (c) has procedures in place to log all activities, including access to, and extraction of, the personal data; (d) uses personal data only in line with the organisation’s instructions – this could be included as a clause in the contract with the organisation / data intermediary undertaking the outsourced work; (e) ensures that only the relevant staff involved in the outsourced work have access to the personal data – these staff should also be well trained in complying with the organisation’s / data intermediary’s personal data protection policies and procedures (for example, the policy and procedure that controls the use and disclosure of personal data by ensuring no internal or external leakage of personal data); and (f) is able to cope with the required document output volume and possesses the flexibility required to adapt to process or workflow changes. 6.12.8 The organisation should adopt the following additional measures to minimise the risks and impact of accidental disclosure of personal data: (a) ensure that the contract with the organisation undertaking the outsourced work can be enforced effectively; (b) conduct regular data audit checks on the organisation / data intermediary undertaking the outsourced work during the outsourcing agreement period to ensure that its personal data protection policies and procedures are adhered to – this may include carrying out an audit check after all processing under the agreement has been carried out to ensure there is no further retention of personal data; (c) consider the possibility of the outsourced work being further sub-contracted by the organisation / data intermediary and, if the organisation permits this, put in place clear parameters for sub-contracting to ensure the sub-contractor(s) / sub-data intermediaries similarly have in place the necessary personal data protection policies and procedures for the work that is being sub-contracted; and (d) ensure all emails sent externally to a group of recipients have the recipients’ email addresses placed in ‘bcc’ fields. 6.12.9 For further information on printing processes, which encompasses mail merging and emailing, see PDPC’s Guide to Printing Processes for Organisations (available at: https://www.pdpc.gov.sg/og); and on processing and sending documents or communications containing personal data, see PDPC’s Guide to Preventing Accidental Disclosure When Processing and Sending Personal Data (available at: https://www.pdpc.gov.sg/og). 114 Resources for Chapter 6 Managing Risk For further information on managing risks see the following PDPC’s, IMDA’s and OWASP’s guides Guide to Handling Access Requests https://www.pdpc.gov.sg/og Guide to Notification https://www.pdpc.gov.sg/og Guide to Accountability under the Personal Data Protection Act https://www.pdpc.gov.sg/og Guide on Data Protection Clauses for Agreements Relating to the Processing of Personal Data https://www.pdpc.gov.sg/og Guide to Managing Data Intermediaries https://www.pdpc.gov.sg/og Guide to Disposal of Personal Data on Physical Medium https://www.pdpc.gov.sg/og Guide to Data Sharing https://www.pdpc.gov.sg/og For exemptions for data sharing arrangements https://www.pdpc.gov.sg/Legislation- and-Guidelines/Exemption-Requests/Data-Sharing-Arrangements Guide to Securing Personal Data in Electronic Medium https://www.pdpc.gov.sg/og Guide on Building Websites for SMEs https://www.pdpc.gov.sg/og Open Web Application Security Project (OWASP) Testing Guide https://www.owasp.org/images/5/56/OWASP_Testing_Guide_v3.pdf) Open Web Application Security Project (OWASP) Application Security Verification Standard (ASVS) https://www.owasp.org/index.php/Category:OWASP_Application_Security_Verification _Standard_Project) The Multi-Tier Cloud Security Standard for Singapore (MTCS SS) https://www.imda.gov.sg/industry-development/infrastructure/ict-standards-and- frameworks/mtcs-certification-scheme https://www.imda.gov.sg/industry-development/infrastructure/ict-standards-and- frameworks/mtcs-certification-scheme/multi-tier-cloud-security-certified-cloud-services Guide to Basic Data Anonymisation Techniques https://www.pdpc.gov.sg/og Advisory Guidelines on the PDPA for Selected Topics - Anonymisation, provides details of the ‘Motivated Intruder Test’ at paragraphs 3.26 to 3.28. https://www.pdpc.gov.sg/ag Guide to Printing Processes for Organisations https://www.pdpc.gov.sg/og Guide to Preventing Accidental Disclosure When Processing and Sending Personal Data https://www.pdpc.gov.sg/og 115