Privacy Regulations and the Water Industry
New regulations both in the United States and internationally are putting pressure on companies to manage private data better. Europe is currently leading the way with the General Data Protection Regulation (GDPR). However, Canada and the US are taking their own steps to protect privacy.
The United States has significantly increased the complexity of meeting privacy compliance by not advancing controls on the federal level through Privacy Shield, creating doubt that Privacy Shield will continue to be adequate in addressing these concerns. Privacy regulations have also been expanded beyond breach notification at the state level, with California (California Consumer Privacy Act-CCPA) and Massachusetts (The Safeguards Regulation) at the forefront.
The conventional approach of providing policies and processes to auditors is no longer adequate for compliance. Privacy regulators want proof that the policies and procedures are enforced, essentially requiring a program with a dedicated a leader, typically a Data Privacy Officer (DPO).
Pro Tip – Establish a minimum baseline for regulatory compliance in the six areas from the below graphic and establish a second baseline of the average compliance level for all of your operations. Then create two roadmaps. The first roadmap is to get all of your operations to a standard level of compliance, and the second is to get your operations to the regulatory baseline. This approach significantly reduces the complexity of becoming compliant and can be done in parallel.
Do You Need a Data Privacy Officer (DPO)?
A DPO is required for European Union (EU) organizations, including where a business has a relationship with EU third parties. While there is currently no requirement for a DPO in North America, many organizations have decided to address the need pro-actively. In creating the role, many companies are struggling to determine whether it fits in Legal, Compliance, or Security. Meanwhile, some companies have established a DPO committee with an executive in an oversight position, and others have farmed out their DPO needs to a third party.
Due to the complexity and newness of the privacy laws, the most successful approach for small to mid-size water organizations is a DPO committee, a DPO service, or a combination of both, depending on international affiliations. For larger organizations, a privacy program is typically run internally with third-party support as needed, or a DPO service is hired and tied closely to legal, compliance, and security groups.
A DPO is a focal point for managing a privacy program and responding to the myriad requests from regulators and customers. The below picture shows how the DPO fits into the privacy program.
Pro Tip – A DPO and the members of a Privacy Committee should belong to the International Association of Privacy Professionals (IAPP) or another reputable privacy organization. These groups provide insights and updates to privacy laws, including articles by privacy professionals on how they are addressing a particular problem.
Purpose of Collecting and Processing Private Data
When collecting or processing private data, an organization must have a justification with a legal basis for processing private data, or the person must have consented to the processing.
In most instances, organizations that support Water Utilities will need to gain a person’s consent, and justify the necessity of the data processing in carrying out a contract or legitimate use interest. When collecting or processing private data, you must provide at least the following information prior to gaining consent; the organization’s name, the type of data, how the data will be used, the purpose of processing, any automated profiling, data transfers, third-party sharing, and the right to withdraw consent.
When carrying out a contract is claimed, you must ensure that you only collect the data that is necessary to carry out the contract. The data cannot be used for anything outside the contract, and you must apply the principle of data minimization.
Legitimate interest should only be applied when there is limited privacy impact, and it does not infringe upon the rights and freedoms of the person. While legitimate interest is the most flexible of all ways to legally collect or process private data, it is recommended that organizations take a conservative approach to what is considered legitimate interest, and they will not be able to use highly sensitive private data.
Most utilities will collect and process private data as part of the performance of a contract or in compliance with a legal obligation, such as performing tasks in the public interest. When processing data for the public interest, you must have a clear basis in law. The processing must be absolutely necessary, and if there is a less intrusive way of achieving the water utility’s goals, those means should be used instead. The water utility must be specific about what the activity is, why it is necessary, and how the data will be used.
Pro Tip – It is a good idea to get help with tying lawful processing and consent management together. There are free tools that can help with determining the best approach for collecting information, such as is available from the United Kingdom (UK) ICO office: https://ico.org.uk/for-organisations/gdpr-resources/lawful-basis-interactive-guidance-tool/.
Consent and Data Subject Rights
Child consent by parents is mandatory globally. Otherwise, consent is probably one of the most significant differences between North American and European Union legislation, although Canada has recently started down the path of being in line with the EU, leaving eyes on what the US will do in the near future. The EU requires all collection and processing of private data to be consented to before collection – and requires disclosure of what the individual is consenting to and their rights and the process to complain must be written in simple, easy to understand language. While there are signs North American legislation is moving in the direction of the EU, some parties are fighting to avoid the requirement of explicit consent, especially in the area of sharing of information intercompany and with business partners.
Data Subject Rights (DSR) must be provided prior to gaining consent from EU citizens and the GDPR has specific rights for individuals around viewing their private data, updating, changing, and requesting it be removed among other rights.
In, North America, CCPA and Canada’s Personal Information Protection and Electronic Documents Act (PIPEDA) are separately addressing consent and DSR, although the current proposals are still lacking, compared to GDPR. The water industry, especially utilities, may want to consider getting ahead of the game and slowly start gaining informed consent to avoid a rush to compliance.
Pro Tip – CCPA has similar requirements as GDPR from a data subject rights perspective, impacting the need for organizations to identify what is being done with private data they have on individuals. Interviews are a common approach to determine where private data is, how it is used, and who has access. While this is a good first step to finding private data, it is typically incomplete, not entirely accurate, and difficult to demonstrate compliance. Consider using technology to not only advance the discovery of private data but also enforce rules or delete data, as appropriate.
Data Register/Record of Processing Activities
The data register, also called Record of Process Activities (ROPA), is probably an organization’s most critical tool. The register provides information about all activities related to private data and can be used for purposes beyond demonstrating compliance. A proper register is used to respond to data subject requests, breach response, and in demonstrating compliance with regulatory bodies – many DPOs will operate their privacy program almost exclusively through this control. ROPA is specifically mentioned in the GDPR, and is an excellent mechanism for complying with North American regulations.
The data register will provide the different types of private data used, along with associated services (Application, Systems), controls, and data flows. Data subject rights, consent type (Informed, Implied, Explicit), and data protection or privacy impact assessment (DPIA/PIA) results will typically be included within a data registry.
Pro Tip – Many organizations start out a data register in an Excel spreadsheet, because it is a practical approach for small organizations with little private data. Technology can dramatically enhance the effectiveness of a data register, but organizations must be deliberate in their technology selection. Security/risk management tools are excellent, although data discovery and enforcement often require integration with other technology. Data analytic tools provide advanced features for monitoring data flows, but their compliance management is not typically as strong as with risk management tools. Other, one-off tools and add-on modules to ticketing systems can be useful as well.
Data Protection Impact Assessments (DPIA)
Data Protection Impact Assessments are different from the typical North American Privacy Impact Assessment (PIA). A DPIA is an assessment of risk impact on an individual, and a PIA demonstrates compliance with the government, without requiring an assessment of risk to the individual.
The first step is to evaluate if a DPIA is needed by determining if private data is being used. Because of the differing guidance from regulators, the rule of thumb is, if you are using private data, perform a DPIA. At a minimum, a DPIA should describe the type of private data, whether it will be used for lawful purpose and legitimate interest, what the data is being used for, who is using it, where it is shared and what controls are securing it. If the data is international in nature, then additional information is needed around transferring data, private data volume, risk analysis on individual impact, and how compliance is demonstrated. The output of a DPIA will feed a data register and define what controls are in place to appropriately protect private data, based on risk.
Pro Tip – A DPIA can be a rabbit hole if you are not careful. We strongly recommend you seek guidance with an established expert that has a background in successfully developing DPIA, ROPA and DSR. A best practice is to develop a simple process for collecting the appropriate information for a DPIA that will be used to update your ROPA and support DSR responses. Enhancing your procedures through technology may be necessary when you are performing or updating DPIAs on a regular basis or have decided on an integrated approach to DPIA, ROPA and DSR.
Breach, Data Subject and Regulatory Responses
It is essential to understand the difference between a security incident and a data breach. A security incident is a compromise of confidentiality, integrity, or availability of an information asset such as an application, system, or database and may not require notification. A data breach is a compromise that results in the confirmed disclosure of private data to an unauthorized party and requires notification that includes information on the response to the breach.
Privacy regulators view a data breach response as one that successfully reduces or removes the risk of harm to individuals and meets notification requirements to both the government and individuals. Internationally, including North America, the required incident response notification timing to regulators is typically 72 hours. The notification to individuals can vary greatly, and each organization should review federal and state laws.
A proper breach response program is highly involved and includes roles and responsibilities throughout the organization. Critical areas in developing a breach response program are; education and training, collecting appropriate information, and defining group responsibilities. Depending on the size and complexity of the organization, groups involved in a breach response include legal, security, HR, marketing, business development, labor unions, and executives.
Pro Tip – Regulators will typically provide guidance on when notifications are required and what type of information is necessary to meet regulatory requirements. Before developing your breach response and notification approach, looking at guidance from your regulators, and you may find that they have done most of the work for you.
If you would like to learn more about this topic, there will be weekly podcasts on the topics above located on Mazarsusa.com