Privacy and Data Security Issues in the Cloud

1. Privacy and Data Security Issues in the Cloud Lisa R. Lifshitz, Partner, Torkin Manes LLP 416-777-8821 llifshitz@torkinmanes.com LEXPERT Cloud Computing Conference 2013 November 28, 2013

2. Agenda • Privacy and Data Protection-Regulatory Framework • Private Sector Organizations • Industry Specific Laws and Standards • Personal Health Information • Your Obligations • Data Protection and Data Transfer • Transferring Data Internationally • Data Breach Notification • CASL • Security • Risks in the Cloud • Technical Standards • Best Practices

3. 1. Regulatory Framework (Private Sector) • In Canada, the federal Personal Information Protection and Electronic Documents Act (“PIPEDA”) regulates the collection, use and disclosure of personal information in the private sector. • “Personal information” is broadly defined in PIPEDA - includes any “information about an identifiable individual”, whether public or private, with limited exceptions. • Excludes the name, title, business address or telephone number of an employee of an organization. • PIPEDA applies to federal works, undertakings and businesses and to all private sector organizations regulated by provinces that do not have substantially similar private sector privacy legislation that collect, use or disclose personal information in the course of their commercial activities. • Examples of federal works and undertakings in Canada include airlines, banks, ferries, broadcasting, inter-provincial railways, interprovincial or international trucking, shipping or other transportation, aviation, banking, nuclear energy, activities related to maritime navigation, and radio stations.

4. Regulatory Framework • PIPEDA also applies to all personal information that flows across provincial or national borders in the course of commercial transactions. • PIPEDA is a general law that applies to the collection of personal information regardless of the technology used. • PIPEDA will not apply in provinces with privacy legislation that is substantially similar to it. • Currently, only Alberta, British Columbia and Québec. • Hot news-Alberta PIPA declared invalid on November 15, 2013 by S.C.C. per Alberta (Information and Privacy Commissioner) v. United Food and Commercial Workers, Local 401case (but invalidity suspended for 12 months). • Manitoba has a new privacy act, the Manitoba Personal Information Protection and Identity Theft Prevention Act that received Royal Assent on September 13 but is not yet in force. • PIPEDA does apply to federal works, undertakings or businesses that operate in those provinces. • In addition, Ontario health information custodians (e.g., physicians, nurses, hospitals, etc.) have been exempted from PIPEDA with respect to personal health information as Ontario has a specific health information privacy statute that applies (more about this later!). • Organizations that operate inter-provincially are required to deal with both provincial and federal privacy legislation.

5. Regulatory Framework • Alberta and British Columbia have also enactedcomprehensive private sector privacy legislation (the Personal Information Protection Act (“PIPA”)in both provinces)which applies generally and includes the personal information of employees. • PIPITPA (Manitoba) will also apply to the personal information of employees (special sections apply). • Québec’s private sector privacy legislation, an Act respecting the protection of personal information in the private sector (“Québec Privacy Act”), is similar in principle to PIPEDA, however, there are important differences indetail. • The Québec Privacy Act applies to all private sector organizations with respect tocollection, use and disclosure of personal information (not just with respect to commercialactivities) and to employee information. • Also applies to private sector collection, use anddisclosure of personal health information. • All Canadian privacy legislation, including PIPEDA, reflects the following ten principles, derived from the Organization for Economic Cooperation and Development Guidelines created in the early 1980’s: (1) accountability, (2) identifying purposes, (3) consent, (4) limiting collection, (5) limiting use, disclosure, and retention, (6) accuracy, (7) safeguards, (8) openness, (9) individual access, and (10) challenging compliance. • All four principle private-sector statutes apply similar principles to comply with these legal obligations. The principles (i) mandate that personal information may only be collected, used or disclosed with the knowledge and consent of the individual; (ii) limit the collection of personal information to what is necessary for identified purposes; and (iii) require that personal information be collected by fair and lawful means.

6. A Word About the Public Sector • Canadian provinces, territories and municipalities also have their own public sector privacy legislation. • Lots of statutes! • See: the Freedom of Information and Privacy Protection Act, R.S.A. 2000, c F-25 (Alberta), Freedom of Information and Protection of Privacy Act, R.S.B.C. 1996, c 165 (BC), Freedom of Information and Protection of Privacy Act, C.C.S.M. c F175 (Manitoba), Personal Health Information Privacy and Access Act, S.N.B. 2009, c P-7.05, replacing the Protection of Personal Information Act, S.N.B. 1998, c P-19.1 (New Brunswick), Access to Information and Protection of Privacy Act, S.N.L. 2002, c A-1.1 (Newfoundland), Freedom of Information and Protection of Privacy Act, S.N.S. 1993, c 5 (Nova Scotia), Freedom of Information and Protection of Privacy Act, RSO 1990, c F-31 (Ontario), Freedom of Information and Protection of Privacy Act, RSPEI 1988, c F-15.01 (Prince Edward Island), An Act respecting Access to documents held by public bodies and the Protection of personal information, RSQ, c A-2.1 (Quebec), Freedom of Information and Protection of Privacy Act, S.S. 1990-91, c F-22.01 (Saskatchewan), Access to Information and Protection of Privacy Act, R.S.Y. 2002, c 1 (Yukon), Access To Information And Protection Of Privacy Act, S.N.W.T. 1994, c 20 (Northwest Territories) and Access To Information And Protection Of Privacy Act, S.N.W.T. (Nu) 1994, c 20 (Nunavut). • Note that the so-called “MUSH sector”- municipalities, universities, schools and hospitals - may be covered by the above legislation so please verify which acts apply!

7. What This Means For the Cloud • All five principle private-sector statutes apply similar principles to comply with these legal obligations. • Several key differences between PIPEDA and the provincial privacy statutes, particularly in relation to data transfers and data breach notification. • These issues will be considered in more detail below. • The legislative situation is more complicated for organizations that conduct business across provincial boundaries. • Within an exempt province, an organization’s use of personal information will be governed by applicable provincial legislation. • However, PIPEDA will apply to organizations located in exempt provinces when they collect, use or disclose personal information across provincial boundaries or internationally. • As Cloud computing involves the use of remotely located computing resources, it will almost invariably involve the use of extra-provincial or international computing resources, thus triggering PIPEDA compliance. • Depending upon the facts, where a Canadian organization transfers personal information into a Cloud computing environment, it may also be potentially required to consider its obligations under four (eventually five) distinct privacy laws.

8. Industry Specific Laws and Standards In addition to the obligations created by PIPEDA and substantially similar provincial privacy legislation, certain industry sectors have additional obligations that apply specifically to their sector. These include: • The Payment Card Industry Data Security Standard (PCI/DSS), • The Office of the Superintendent of Financial Institutions standards • Guideline B-10 (for outsourcing) • OSFI Guidelines E-4A and E-4B concerning Record Keeping Requirements. • OSFI Guidelines E-5 concerning Retention/Destruction of Records; and • Additional legislative systems that apply to holders of health information in various provinces.

9. The Payment Card Industry Data Security Standard The Payment Card Industry Data Security Standard (PCI DSS) provides technical and operational requirements for organizations that store, process, or transmit data on payment card holders, such as merchants, and card issuers. Where credit card transactions take place, or card holder data is stored on the Cloud, PCI DSS will apply to Cloud Providers. The PCI DSS creates requirements in six key areas:

10. The Payment Card Industry Data Security Standard Network Security • At a minimum, organizations are required to install firewalls to protect their network, and sensitive areas within their network, from unauthorized access. Direct public access to the cardholder data environment is to be blocked. • The PCI DSS directly prohibits using vendor defaults for passwords or system parameters, and requires the deletion of all unused accounts. Protecting Cardholder Data • Cardholder data must be protected by security methods such as encryption, truncation, or hashing when it is stored or transmitted over a network. Data retention should be limited to that required by legal or business reasons, and certain highly sensitive information, such as Card Verification Numbers, and PIN codes should not be stored.

11. The Payment Card Industry Data Security Standard Maintaining a Vulnerability Management Program • Organizations must use up to date anti-virus software on all systems. These systems must generate logs of their audit activity. All systems and software must be kept up to date using the most recent vendor security patches. Implementing Access Controls • Access to sensitive information should be limited to personal who actually need to know it, based on their business responsibilities. This system should rely on user identification, and deny access to all users not specifically allowed access. • Access to the physical facility itself should be controlled to prevent unauthorized access to data.

12. The Payment Card Industry Data Security Standard System Monitoring and Testing • Access to the system, and actions taken by users, must be logged to detect and minimize data breaches. The audit trail itself should be protected from alteration and retained for at least a year. • System vulnerability should be tested regularly, including checking for wireless access points. Information Security Policy • The organization should implement a security policy that informs personnel of the expectations placed on them. The policy should detail all of the PCI DSS requirements, include usage policies for critical equipment, such as wireless and remote access technology, and include an incident response plan.

13. The Office of The Superintendent of Financial Institutions • The Office of the Superintendent of Financial Institutions (OSFI) is a federal regulatory body with jurisdiction over federally regulated deposit taking entities, such as banks, insurance institutions, and pension plans. • “FREs” incluees banks, corporate bodies under the Trust & Loan Companies Act, credit unions, insruance companies and the Canadian branches of foreign banks and insurance companies. • The OSFI “Outsourcing of Business Activities, Functions and Processes” (Guideline B-10) will apply to outsourcing agreements entered by subject organizations and Cloud Providers. • Prior to outsourcing any business functions, entities subject to the OSFI guidelines are required to determine whether the agreement is “material” by considering: • The impact of the arrangement on their finances, reputation and operations, • The ability to have internal controls if the service provider were to fail, • The difficulty and cost of finding an alternate service provider or conducting the activity in-house. • Arrangements deemed “material” must be subject to a risk management program that meets specified requirements.

14. The Office of The Superintendent of Financial Institutions Outsourcing Risk Management: • OSFI requires organizations to undertake a due diligence process to determine how to manage the risk associated with the outsourcing process. • This process must include an assessment of the service provider itself, including its operational practices, financial stability, and for foreign service providers, the legal requirements of the jurisdiction in which they are located, and any political, social or economic conditions effecting it. • When the decision is made to proceed with outsourcing, this must be documented in a written contract. Outsourcing Agreements: • Ultimately, OSFI requires organizations to maintain their own accountability for outsourced services. To ensure this, the contract must address: • The scope of the service being provided, • How frequently and in what form the service provider (here, the Cloud Provider) will report to the organization, • The contingency procedures/business continuity plans in place in case the system breaks down, • The audit rights of the organization, • Rules and any limitations on subcontracting, • The confidentiality and security requirements specified by the organization

15. Application to Cloud Computing • On February 29, 2012 OSFI issued a “Memorandum re New technology-based outsourcing arrangements” that confirmed that the expectations contained in Guideline B-10 remain current and continue to apply in respect of technology-based outsourcing services, including Cloud computing. • In particular, federally regulated financial institutions should consider their ability to meet the expectations contained in Guideline B-10 in respect of a material arrangement, with an emphasis on i) confidentiality, security and separation of property; ii) contingency planning; iii) location of records, iv) access and audit rights, v) subcontracting, and vi) monitoring the material outsourcing arrangements.

16. Personal Health Information • Be aware that some Canadian provinces have enacted sector specific healthcare privacy legislation. These are: • Alberta (the Health Information Act); • Manitoba (the Personal Health Information Act); • New Brunswick (the Personal Health Information Privacy and Access Act); • Newfoundland and Labrador (the Personal Health Information Act); • Ontario (the Personal Health Information Protection Act, 2004); and • Saskatchewan (the Health Information Protection Act). • We will focus mainly on PHIPA (Ontario).

17. A Word About PHIPA • Under PHIPA, “Personal health information” is broadly defined as: “identifying information about an individual in oral or recorded form”, and includes information that (a) relates to the physical or mental health of the individual, including information that consists of the health history of the individual’s family, (b) relates to the providing of health care to the individual, including the identification of a person as a provider of health care to the individual, (c) is a plan of service within the meaning of the Home Care and Community Services Act, 1994 for the individual, (d) relates to payments or eligibility for health care, or eligibility for coverage for health care, in respect of the individual, (e) relates to the donation by the individual of any body part or bodily substance of the individual or is derived from the testing or examination of any such body part or bodily substance, (f) is the individual’s health number, or (g) identifies an individual’s substitute decision-maker. “Identifying information” means information that identifies an individual or for which it is reasonably foreseeable in the circumstances that it could be utilized, either alone or with other information, to identify an individual. • PHIPA requires health information custodians to take reasonable steps to ensure that the personal health information in their custody or control is protected against “theft, loss, and unauthorized use or disclosure”. • Further, the custodian must protect against unauthorised copying, modification, and disposal. • If a health information custodian wishes to engage in Cloud computing, it must engage a Cloud Provider that has knowledge and understanding of the legislative requirements applicable to the industry.

18. 2. Key PIPEDA Principles re Data Protection and the Cloud • Organizations are responsible for personal information in its possession or custody, including information that has been transferred to a third party for processing. (Principle 4.1.3). • The organization shall use contractual or other means to provide a comparable level of protection while the information is being processed by third parties. (Principle 4.1.3). • Organizations that collect, use or disclose personal information are required to provide security for that information that is appropriate when considering its sensitivity. (Principle 4.7) • In creating safeguards for personal information, PIPEDA obligates organizations to implement physical measures, organizational measures and technological measures to ensure adequate safety. • Physical data protection mechanisms may include restricting access to secure locations. • Organizational data protection measures will include ensuring that only certain personnel have access, or the access keys, to personal information. • Most important in Cloud computing, technological measures will include data encryption, passwords and access keys. • The extent to which each of these protection methods is required will vary with the sensitivity of the information in question; more sensitive information will require greater protection and vice versa.

19. Key PIPEDA Principles • In addition to protecting personal information in their control, organizations are required to limit their use, disclosure and retention of personal information to those purposes disclosed when the information was first collected, unless additional consent is established. (Principle 4.2) • After the initial purpose has been achieved, the personal information must be destroyed, erased, or made anonymous. Organizations shall develop guidelines and implement procedures to govern the destruction of personal information (Principle 4.5.3). • Under a separate provision, Principle 4.8, PIPEDA requires organizations to be open about their policies and practices relating to the management of personal information. • Taken together, Principle 4.1.3 and Principle 4.8 require that the covered organization at a minimum (1) have in place contractual or other means to provide a comparable level of protection, (2) inform its customers about its policies and practices related to the management of personal information, and 3) notify customers that their personal information may be available to a foreign government or its agencies under a lawful order made in that country. • These obligations will continue to apply to organizations that outsource the processing of personal information to third party Cloud Providers.

20. Alberta PIPA Obligations • Alberta’s PIPA recently amended to require that organizations must notify individuals before transferring personal information to a foreign service provider (includes Cloud Providers). • Organizations that use foreign service providers and that directly or indirectly transfer personal information outside Canada about an individual that was collected with the individual’s consent are now required to: • Notify individuals before or at the time of collecting or transferring the information in writing or orally if the service provider outside of Canada will collect personal information on behalf of the primary organization; • Notify individuals of the way in which the individual may obtain access to written information about the organization’s policies and practices with respect to service providers outside Canada; and • Provide the name or position or title of a person who is able to answer on behalf of the organization the individual’s questions about the collection, use, disclosure or storage of personal information by service providers outside Canada for or on behalf of the organization. [Section 13.1(1)] • Note that definition of “service provider” means any organization, including, without limitation, a parent corporation, subsidiary, affiliate, contractor or subcontractor, that, directly or indirectly, provides a service for or on behalf of another organization.

21. New Cloud Guidelines From Our Privacy Regulators • In June, 2012 the OPC, the Office of the Information and Privacy Commissioner of Alberta and the Office of the Information & Privacy Commissioner for British Columbia issued a joint Guidance Document called “Cloud Computing for Small and Medium-sized Enterprises: Privacy Responsibilities and Considerations”. • The focus of the OPC Guidance Document was to remind SMEs that under Canada’s private sector privacy legislation, an organization that collects personal information from an individual is accountable for the personal information even when it is outsourced for processing to third-party providers. • Thus, all businesses in Canada, regardless of their size, are ultimately accountable for the personal information they collect, use and disclose even if they outsource personal information to a service provider that operates in the Cloud. • The privacy regulators confirmed that (i) many standard Cloud computing agreements legal terms that are not sufficient to allow SMEs to meet their Canadian privacy obligations; (ii) standard Cloud computing agreement often allow a provider to unilaterally change the agreement, limit its liability for the information, and/or subcontract to various other providers. • However, as confirmed by the OPC, SMEs must use contractual or other means to ensure that personal information is appropriately handled and protected by the Cloud Provider.

22. New Cloud Guidelines • SMEs using Cloud computing services should: • Limit access to the information and restrict further uses by the provider; • Ensure that the provider has in place appropriate authentication/access controls; • Manage encryption; • Ensure that there are procedures in place in the event of a personal information breach or security incident; • Ensure periodic audits are performed; and • Have an exit strategy • SMEs must pro-actively maintain control over personal information that is sent to a Cloud Provider, and take steps to prevent and limit secondary uses of personal information. • Due diligence on the part of the organization will be required before signing a standard Cloud agreement and moving personal information to the Cloud. • SMEs must (i) clarify what, if anything, the prospective Cloud Provider will do with the personal information provided; (ii) seek customers’ consent for new uses of their personal information; and (iii) always keep in mind the reasonable expectations of the individual.

23. What Does This All Mean For the Cloud? • Organizations subject to PIPEDA must ensure that any personal information transferred to a Cloud Provider is dealt with in a manner that meets the organization’s own legal obligations. • This will require the Cloud Provider to be contractually bound to secure the information in an adequate manner, considering the sensitivity of the information, as well as the specification of data protection mechanisms and any data breach notification requirements will be discussed. • Cloud Provider must be required to use the information solely for the purpose for which it was collected by the organization and disclosed to the Cloud Provider (and for no other purpose). • The Cloud Provider must not be allowed to retain or use the information after the use disclosed to the individual has been achieved, or after the Cloud agreement is terminated. • Cloud Provider may be located in a foreign jurisdiction and may resist being contractually bound to comply with the privacy obligations established in Canadian law. • Standard form contracts are often not adequate to allow organizations to meet their privacy obligations under Canadian law, and indeed, may allow the Cloud Provider may amend the agreement, with or without notice to the organization. • Be aware that the legal onus is on the outsourcing organization to ensure that any Cloud Provider to whom personal information is transferred complies with Canadian privacy laws. • Customers must engage in due diligence efforts re their proposed Cloud Providers! • Regulators also provided two pages of “Cloud Computing Key Questions” re accountability, security, secondary uses, knowledge, consent and transparency, control, accessibility and jurisdiction/access.

24. Transferring Data Internationally/Patriot Act Concerns • Currently, PIPEDA, the B.C. PIPA, the Quebec PIPA and the Manitoba PIPITPA do not address the international transfer of personal information. • As previously discussed, Alberta’s PIPA contains a positive obligation for organizations to notify individuals before transferring personal information to a Cloud Provider outside of Canada. • However, the Office of the Privacy Commissioner of Canada (“OPC”) encourages organizations to make it clear to individuals when their personal information may be processed in foreign jurisdictions and may be accessible to law enforcement and national security authorities in those jurisdictions. • In its 2009 Guidelines for Processing Personal Data Across Borders, the OPC states that organizations must be transparent with relation to trans-border data flows (including advising customers that their personal information may be sent to another jurisdiction for processing). • Much concern over possible Patriot Act intrusion. • Trio of cases established that PIPEDA cannot prevent U.S. authorities from lawfully accessing personal information of Canadians held in Canada or U.S. • PIPEDA cannot force Canadian companies not to outsource to foreign-based service Providers. • Organizations must be transparent about personal information handling practices and protect personal information in the hands of third party processor (foreign or local).

25. International Transfer Of Personal Information - Is the Tide Shifting? IPC: Ministry of Natural Resources Licensing Automation System Privacy Investigation by the Ontario Privacy Commissioner (June 2012 – PC 12-39) • Ministry awarded a US-based public company, Active Outdoors, a contract to host and maintain a Licensing Automation (LAS) system database relating to hunting and fishing licenses. • Individuals in Ontario wishing to apply for a hunting and fishing license must submit personal information in the LAS database. • IPC received a complaint about the privacy and security of the personal information stored in the LAS, particularly regarding the fact that the personal information of Ontarians would be subject to American laws, including the Patriot Act. • IPC investigated and confirmed: • No legislative prohibition against the storing of personal information outside the province of Ontario or Canada. • FIPPA does require provincial institutions to ensure that reasonable measures are in place to protect the privacy and security of their records containing personal information. • The risk that law enforcement agencies may access personal information is not restricted to information held in the US – Canadian law enforcement agencies have similar ‘robust powers’.

26. International Transfer Of Personal Information • Law enforcement agencies in Canada, the US and other countries have the ability to reach across borders to access personal information under various laws and agreements. • IPC confirmed stance of the OPC that privacy risks posed by the Patriot Act are similar to those found in Canada; the privacy protection afforded a US provider is comparable to that of a Canadian provider. • FIPPA does not prohibit provincial institutions from outsourcing services on the basis that foreign law, i.e. the Patriot Act, may apply. • No prohibition on the storage of personal information by government institutions by the province. • KEY QUESTION: Has the MNR taken reasonable steps to protect the privacy and security of their records in their custody and control via contract? • IPC reviewed key contractual provisions relating to data ownership, collection, use and disclosure, confidential information, notice of compelled disclosure, subcontracting, security, retention and destruction, audits and governing law. • MNR still needed to finalize its retention and destruction schedule; otherwise MNR found to have put in place reasonable measures to protect personal information.

27. Data Breach Notification - Alberta • Currently, only Alberta has a mandatory security breach reporting requirement that applies to all private sector organizations within the province. [Section 34.1] • The Alberta PIPA now requires organizations to notify the Alberta Privacy Commissioner (“APC”) in instances where personal information is lost, accessed, or disclosed without proper authorization. • This reporting obligation will arise only where the breach results in a “real risk of significant harm” to the individuals affected. • APC has interpreted the significant harm threshold to be met where the breach presents “a material harm; it has non-trivial consequences or effects. • Examples may include possible financial loss, identity theft, physical harm, humiliation or damage to one’s professional or personal reputation.” • Any such risk must be real, not “merely speculative” or “hypothetical or theoretical”.

28. Mandatory Data Breach Notification - Manitoba • Under new PIPITPA, an organization is obligated to notify the individual directly if personal information is stolen, lost, or accessed in an unauthorized manner. • This obligation does not apply where (i) a law enforcement agency is investigating the theft, loss or unauthorized access; or (ii) the organization is satisfied that it is not reasonably possible for the personal information to be used unlawfully. • PIPITPA does not have a harm threshold - this seems to suggest that all breaches can trigger notification, subject to the above. • PIPITPA also creates a right of action for an individual against an organization for damages arising from its failure to: a) protect personal information that is in its custody or control; or b) provide reasonable notice if the organization was not satisfied that the lost, stolen or accessed information would not be used unlawfully. • Organizations found guilty of failing to protect PI, failing to notify a significant security breach, willfully collecting, using or disclosing PI in contravention of the Act, willfully attempting to gain or gains access to PI in contravention of the Act or disposing of or altering, falsifying, concealing or destroying PI or any record relating to PI, or directing another person to do so, with an intent to evade a request for access to the information or the record are subject to a summary conviction and fines of up to $10,000 for an individual and $100,000 for a person other than an individual (due diligence defense).

29. Data Breach Notification - PIPEDA • Currently, PIPEDA does not create an explicit obligation to notify either the OPC or the individuals involved of breaches of security that affect personal information. • In August 2007, the OPC published voluntary guidelines entitled “Key Steps for Organizations in Responding to Privacy Breaches” to assist organizations in responding to such situations. The OPC indicates that there are four key steps to consider when responding to a breach or suspected breach: • contain the breach by taking immediate steps to stop any further information from being disclosed and undertake a preliminary assessment of the situation; • evaluate the risk associated with the breach by considering the sensitivity of the information involved, whether it was encrypted, how it may be used, and the risks to the individual resulting from that use; • notifying the individuals if the privacy breach creates a risk of harm to the individual; and • developing a plan for the prevention of future breaches. • As these guidelines are voluntary, there is, strictly speaking, no penalty for organizations that do not follow them. • As providing adequate security for personal information is an obligation under PIPEDA, the OPC is able to investigate security breaches, either in response to a complaint or on its own initiative and may issue a report setting out the Commissioner’s findings, recommendations, and request the organization provide the OPC with notice of any actions that have been taken to implement the Commissioner’s recommendations.

30. Proposed Amendments to PIPEDA – Bill C-475 • Previous attempts to amend PIPEDA have repeatedly been made to include a mandatory breach notification requirement. Past Bill C-29 died on paper when a federal election was called in the spring of 2011. • Bill C-475 - most recent effort to amend PIPEDA re mandatory data breach notification. • If passed, organizations will have to notify the OPC of any incident involving the loss or disclosure of, or unauthorized access to, personal information where a “reasonable person would conclude that there exists a possible risk of harm to an individual as a result of the loss or disclosure or unauthorized access”. • Factors that are relevant in determining whether there is a real risk of harm include (a) the sensitivity of the personal information; and (b) the number of individuals whose personal information was involved. • “Harm” includes bodily harm, humiliation, embarrassment, injury to reputation or relationships, loss of employment, business or professional opportunities, financial loss, identity theft, identify fraud, negative effects on credit rating and damage to or loss of property. • Notification must be made without “unreasonable delay after the discovery of the loss or disclosure of, or unauthorized access to, personal information”.

31. Bill C-475, continued. • It will be up to the OPC to decide whether the reporting organization must notify affected individuals to whom there is an appreciable risk of harm and if the OPC makes that determination, the reporting organization must notify the affected individuals “without unreasonable delay”. • Organizations can always notify individuals on their own initiative and inform the OPC if they do so. • The OPC can also order organizations to comply with the Act (on a time-limited basis ) and force them to take certain actions, including ceasing to collect, use or disclose PI and publishing a public notice describing their corrective actions. • If the organization fails to comply with the OPC’s orders or misses the OPC’s timelines, the OPC has a right of action against the organization. • Bill went through a second reading on October 22, 2013.

32. Data Breach Notification – Health Care Some Provinces Do Not Expressly Require Notification • In Alberta, Manitoba and Saskatchewan, there are no express requirements contained in the relevant legislation to notify the person to whom the information relates (or the relevant Privacy Commissioner) where a privacy breach is detected. • This situation is somewhat odd, as in Alberta there does exist an express requirement in the non-sector-specific Alberta PIPA for notification to the APC of a breach as discussed above. • In Alberta, while there exists no regulatory requirement to provide notice to the APC or any other person of a privacy breach, should the APC become aware of a breach he or she may order that notice be provided, either to specifically affected individuals or to the general public.

33. Data Breach Notification – Health Care Ontario Requires Notification of Affected Individuals Only • Of the provinces surveyed, Ontario is unique in requiring that personal health information custodians notify individuals only (and not the OIPC) of a privacy breach. • Subsection 12(2) of PHIPA states as follows: • (2) Subject to subsection (3) and subject to the exceptions and additional requirements, if any, that are prescribed, a health information custodian that has custody or control of personal health information about an individual shall notify the individual at the first reasonable opportunity if the information is stolen, lost, or accessed by unauthorized persons. • The language uses the imperative “shall” and appears to make such notification mandatory, regardless of the severity of the breach or the sensitivity of the patients to being so informed. • However, the decisions so far taken under PHIPA by the OIPC indicate very clearly that the legislation is not interpreted in that manner in actual fact.

34. Health Requirements Some Provinces Require Notification of Affected Individuals and the Privacy Commissioner • New Brunswick, Newfoundland and Labrador have comprehensive systems dealing with breach notification, which include informing in appropriate cases both the affected individuals and the Privacy Commissioner. • In New Brunswick, the duty to notify is conditional on a threat assessment made by the custodian. • Newfoundland and Labrador has a similar set of legislation, with a unique twist: the custodian may, as in New Brunswick, perform a threat assessment and determine that the individuals need not be informed; however, the custodian must make an entirely different assessment as to whether there has been a “material breach” in order to determine whether or not to inform the Privacy Commissioner. • If there has been a “material breach”, the Commissioner may override the custodian’s threat assessment and order notification of individuals.

35. Data Breach Notification In The Health Care Sector • Legislative situation in Canada with respect for mandatory breach notification for health information is extremely varied. • Some provinces lack health sector specific privacy legislation at all, while in those provinces that do have it, some do not expressly require notification while others variously require notification of affected individuals and/or the provincial Privacy Commissioner. • Insist on mandatory data breach notification in your Cloud agreements!

36. Canada’s Anti Spam Legislation (CASL) • Canada’s Anti-Spam Legislation (CASL) will come into force in 2014. • Industry Canada regulations are final and have been signed by the Minister. • While still confidential, they are purported to have “a lot of changes” since the last draft. • According to Kelly-Anne Smith, legal counsel to CRTC, there is one change that parties who must comply will be “happy about” (not clear what this is yet). • Though it is directed at “damaging and deceptive ” forms of “spam”, CASL applies broadly to all “commercial electronic messages” sent to an “electronic address”. • “Commercial electronic messages” will include messages sent by any means of telecommunication, including text sound, voice, or image messages. • This will capture not only email, but other forms of electronic communication, such as text messaging, and potentially social media, including Facebook and Twitter.

37. CASL • CASL takes a prohibitive approach to Commercial Electronic Messages, prohibiting all but those messages that comply with its requirements. • Under CASL: • Electronic messages require consent from the recipient, either express or implied; • The message must contain prescribed disclosure; and • The message must contain an unsubscribe mechanism in prescribed form. • The precise requirements for commercial electronic messages (“CEMs”) will be provided by regulations. Under the regulations CEMs must specify: • The name of the person sending the message and the person, if different, on whose behalf it is sent and the names by which those persons carry on business; • If applicable, an indication which person sent the message and on whose behalf it was sent; • The mailing address and one or more of the following: telephone number, email address and website of the person who sent the message and, if applicable, on whose behalf it was sent; and • An unsubscribe mechanism using the same electronic means as the CEM, and specifying an electronic address to which the request may be sent.

38. CASL – Implications For Cloud Computing • The detailed requirements of CASL apply to all CEMs that are sent from or accessed from a computer in Canada. • Cloud Providers located in Canada would be obligated to comply with CASL when sending CEMS to non-Canadians, on behalf of a non-Canadian client. • This result may incentivize the use of non-Canadian Cloud Providers. • Further, Canadian companies outsourcing their CEM communications with Canadians to a foreign Cloud Provider would need to ensure that the service provider is able to comply with the CASL requirements. • The disclosure requirements in the regulations also create barriers to the use of a Cloud computing model when the need for an unsubscribe mechanism is considered. • CASL requires the message to permit the recipient of the message to indicate they no longer wish to receive CEMs from the sender of the message OR the person who caused it to be sent. • As a single Cloud Provider may be sending CEMs on behalf of multiple organizations, this requirement may necessitate detailed unsubscribe language so that message recipients understand the effect of the unsubscribe mechanism. • In the absence of such revisions or clarifications, CASL may pose a substantial regulatory barrier to the use of a Cloud service model for sending CEMs to Canadians or from Canada.

39. Security (An Overview) • Security is often cited as a major issue in Cloud Computing, partly because of general concerns arising from loss of control, partly because data protection laws require data holders/custodians to take appropriate security measures to protect personal data. • Are the issues the same as regular IT services or different for the Cloud? • Do the risks outweigh the benefits? • You need to ask many questions of your Cloud Provider to determine whether their policies and procedures are sufficient to meet your needs (including business and legal requirements). • However, many Cloud Providers are not forthcoming about their security arrangements. • Many Cloud Providers consider it detrimental to their own security policies to provide full details of their security practices to all prospective customers or allow data centre visits • Too much transparency about security can itself compromise security. • Cloud Providers may allow users to see a summary or high-level overview of security policies, measures and standards. • St Marys’ 2012 survey: some customers (governments, financial institutions) allowed security-vetted personnel to make escorted data centre visits, view specific documentation such as its ISO27001 policies and procedures and other detailed information and discuss issues with the Cloud Provider’s security/security monitoring personnel. • NO ability to take away copies of security documents; restricted to viewing hard copies in closed rooms.

40. Security Issues to Raise (A Partial List) Privileged User Access • Who will manage your data? • Who will have access to your data? • Consider physical, logical and personnel controls to protect proprietary and confidential information. Regulatory Compliance • Will you be able to conduct an audit of the Cloud Provider’s security processes and procedures? • Will you be able to require the Cloud Provider to comply with security certifications? Data Location • Where will the data be stored? • Will the Cloud Provider commit to storing and locating your data in a specific jurisdiction? • Will the Cloud Provider agree to comply with local privacy laws applicable to your organization? • Consider physical safety of the infrastructure, political risk and data breaches. Data Segregation • What will the Cloud Provider do to ensure that your data is segregated from other users of the Cloud? • Consider the encryption techniques used and other technological measures used.

41. Security Issues to Raise Recovery • What is the Cloud Provider’s disaster recovery plan? • What will happen to your data in the event of a disaster? • What will happen to the Cloud in the event of a disaster? Investigative Support • Will the Cloud Provider commit to enable you to respond to discovery requests and other investigations? Long-Term Viability • How will you retrieve data stored in the Cloud? • What format will it take?

42. Security Risks That Are Unique To The Cloud Resource Pooling/Multi-Tenancies • This is what the public cloud is all about: pooling together resources for use by multiple customers. • Physical security issues are the main concern with respect to the segregation of data in the Cloud. • Ensure that individual customers do not impact operations of other “tenants” of the Cloud and that tenants do not have access to any other tenant’s actual or residual data or network traffic. • Greater risk, but offers economies of scale to SMEs. Viruses, Hackers and other Infrastructure Abuses • Cloud is an easy target for criminals. • As quickly as technology improves, criminals improve their tactics. • Registration systems may be weak and fraud detection mechanisms can be minimal in the Cloud. • Look for strict registration and validation processes, fraud monitoring, validation and monitoring of customer network traffic.

43. Security Risks That Are Unique To The Cloud Insecure APIs • API is your access to the Cloud. • Ensure that there are authentication and access controls, encryption and activity monitoring tools. • If you are going to customize an API, ensure that your IT department interfaces with the Cloud service provider to test for security. Data Loss or Leakage • Risk is increased over traditional IT. • Access controls, encryption, protection of data in transit, disposal challenges, risk of association, data centre reliability, disaster recovery plans and other physical and remote access controls are all important to prevent data loss or leakage.

44. Security Risks That Are Unique To The Cloud Use of Data by Cloud Provider • Opaque or transparent? • Cloud Provider should NOT have or require access to data that is stored in the Cloud. • May be minor exceptions for application maintenance, etc. • Ensure strong confidentiality obligations are placed on the Cloud Provider to protect your data accordingly. The “Unknown” • There is always the risk of the unknown when it comes to technology… • Protect against it by ensuring top notch security measures and protocols are in place at your organization and Cloud Provider. Question: Whose security policy will be followed? Usually that of the Cloud Provider, ideally based on “industry best practice” or specific standards, ISO27001, but often reserving rights to change their own policy unilaterally.

45. Technical Standards (Just To Name A Few) • Independent certifications to objective security standards often used as a compromise solution to address security concerns. • While industry standards and certifications specific to Cloud security have not been fully developed, organizations such as the Cloud Security Alliance, NIST, Open Data Centre Alliance and CIF are working currently working on these. • Specific Cloud standards are evolving • International Organization for Standardization (ISO): • ISO/IEC 177888 (Cloud computing-vocabulary and overview)-2nd Committee Draft. • ISO/IEC 17789 (Reference Architecture)- Committee Draft. • ITU-T/Study Group 13 (Future networks including cloud computing, mobile and next generation networks, security). • ISO/IEC 27017 (Code of practice for information security controls for cloud computing services based on ISO/IEC 270002)-5th Working Draft. • ISO/IEC 270818 (Code of practice for data protection controls for public cloud computing services) – Committee Draft. ISO/IEC 27036-4 (Information security for supplier relationships-Part 4: Guidelines for security of cloud services)-2nd Working Draft. • ISO/IEC 27040 (Storage Security) -3rd Committee Draft.

46. Evolving Cloud Computing Standards • NIST (National Institute for Standards and Technology)-Information Technology Laboratory • Guidelines on Security and Privacy in Public Cloud Computing • The NIST Definition of Cloud Computing • Cloud Computing Synopsis and Recommendations • NIST Cloud Computing Standards Roadmap (etc). • Cloud Security Alliance • Security Guidance for Critical Areas of Focus in Cloud Computing • Open Certification Framework • Cloud Controls Matrix • Trusted Cloud Initiative Reference Architecture Model • Top Threats to Cloud Compting • Security as a Service (SecaaS) Implementation Guidance. See the materials for details of ongoing standards from OASIS (Organization for the Advancement of Structured Information Standards), the IEE, Trusted Computing Group (TCG), Storage Network Industry Association (SNIA), The Open Group, Distributed Management Task Force, etc.

47. Pre-contractual Penetration Testing • Many customers, particularly those from regulated sectors, want to conduct pre-contractual security penetration testing to check integrity and robustness of providers’ security policy and IT systems and how well users’ data are separated from other users. • Most Cloud Providers do not agree, because of potential adverse impact on other users’ services or data. • St Marys’ 2012: acceptable if the user agreed to unlimited liability for any damage cause and to constrain testing as regards timing, from which IP address, etc. • Usually confined to a ‘sandbox’, i.e. a specially designated area, to avoid possible damage to systems. • Possible compromise: Cloud Providers to conduct their own tests (or use a third party) and share the results with current or prospective customers. • Specify frequency, type in the Cloud Agreement. • Ongoing user penetration tests considered unusual. • Much reliance on certifications.

48. How To Protect Yourself – Best Practices • Many of the privacy and security risks discussed above can be protected against/mitigated through contractual obligations placed on the Cloud Provider. • The following is a non-exhaustive list of matters that should be addressed accordingly in your Cloud contract. Security Safeguards • Critical that technical, physical and organizational safeguards be established and maintained by the Cloud Provider. • The Cloud Provider should adhere to these requirements and any applicable (industry specific) policies and procedures that you provide or require in order to protect against and mitigate security risks as well as demonstrate compliance with any statutory/regulatory requirements, such as those under PIPEDA and the provincial PIPAs. • Obligate the Cloud Provider (and its subcontractors, as necessary) to fully cooperate and provide assistance in respect of remedying any security breach experienced by the Cloud Provider (or its subcontractors) that affects your organization or its data accordingly. • Ensure the Cloud Provider (and the Cloud Agreement) requires security incidents to be promptly reported to customer.

49. Best Practices Technology and Encryption Standards • If technology and encryption standards are not addressed as part of the general security safeguards to be employed by the Cloud Provider, require the Cloud Provider to comply with any one or more, as appropriate, of the technical security standards discussed herein, or to adhere to certain technological and encryption standards to ensure the protection and authenticity of the data and assets entrusted to the Cloud. Location • Seek additional clarity to gain a better understanding of the potential risks to your organization’s data, what, if any, obligations flow from the location of such data, and how you can mitigate any risks that may arise. • Obligate the Cloud Provider to either provide certain representations and warranties as to the location of the Cloud infrastructure or covenant not to remove the Cloud infrastructure from its current jurisdiction. • If the location of the infrastructure is to be moved by the Cloud Provider, include an obligation for the Cloud Provider to provide prior written notice of such move so that your organization can comply with its legal requirements accordingly.

50. Best Practices Confidentiality Obligations • Obligation on the Cloud Provider to protect any confidential information of your organization, which should include, among others, personal information, intellectual property and proprietary information. • Watch for limitations of liability (namely attempts to minimize/disclaim most of it), including any exclusions of indirect damages or other damages in respect of a breach of these obligations. • Attempted limitations and carve-outs are especially pertinent when dealing with data breaches and/or data loss. Privacy/Data Protection • Cloud Provider should comply with all applicable privacy laws, including, but not limited to, those applicable pursuant to the governing law of the contract, the jurisdiction in which the Cloud infrastructure is located, as well as the local privacy laws applicable to your organization. • Require the Cloud Provider to enable your organization to conduct sufficient due diligence and audits to ensure that these obligations will be met and to fix any deficiencies noted.