When speaking about cloud, the terms “data sovereignty” and “data residency” come up frequently. Within the private sector, there is still a great deal of FUD (fear, uncertainty, and doubt) about topics such as the Patriot Act. A fair bit has been written about this topic here on ITBusiness.
The abridged version of the discussion is simply that while private companies may want to keep data in Canada for customer perception or personal comfort reasons, there is no valid regulatory reason not to put data outside of Canada. There is also not much extra protection from U.S. law enforcement. See “Keeping data here no protection against US” as a good article on the topic.
The question then moves to public sector organizations who have to abide by different regulations and privacy legislation than most private sector companies. PIPEDA impacts everyone, and needs to be taken very seriously by public sector, but what about regulations such as the Personal Health Information Protection Act (PHIPA) and Municipal Freedom of Information and Protection of Privacy Act (MFIPPA). Do they limit what public sector organizations can put in the cloud?
To figure this out, I sat down with Tracy Ann Kosa, a senior strategist in privacy at Microsoft Corp. and a doctoral candidate in Computer Science at University of Ontario Institute for Technology working on creating models for measuring privacy. Here’s an edited transcript of our conversation:
Brian Bourne: I often hear things like “we have patient information” or “we have constituent information” and then “we can’t put that in the cloud.” I guess the first question, is what regulations impact those who hold this type of information?
Tracy Ann Kosa: Tricky question, that really depends on the physical location of the client – and their clients. A company in Ontario would be required to demonstrate compliance with anywhere from one to five different privacy laws. Generally private sector companies are covered by PIPEDA, health care organizations are covered under PHIPA, and government organizations are regulated by MFIPPA (municipalities) and / or FIPPA (provincially). A private sector company that works with a long term care facility may be required to comply with both PIPEDA, MFIPPA and PHIPA. It can get complicated, so often the best thing is to understand the most restrictive requirements that could apply, and work backwards from there.
BB: What do those regulations say about where the data resides?
TAK: None of these laws set requirements on data residency. PHIPA and PIPEDA are consent based laws, which means that organizations subject to those Acts must provide information to the data subject in a consent document and obtain express (e.g. written) or implicit (e.g. oral) permission. M/FIPPA and FIPPA are notice based laws, which means that organizations subject to those Acts must provide information to the data subject in a notice and post that in a place that people can see it; online, in an office, etc. The Ontario government also has a Corporate Operating Policy on the Protection of Personal Information, similarly it contains no requirements on data residency for service providers.
Both notice and consent documents are intended to provide transparency around information practices. Neither expressly require a statement indicating where data will reside, but it’s a good practice to be open with your customers and clients. (Author note: I’ve never seen a privacy statement discuss what IT systems are being used.)
BB: What level of protection is required?
TAK: PHIPA s.12 states: “a health information custodian shall take steps that are reasonable in the circumstances to ensure that personal health information in the custodian’s custody or control is protected against theft, loss and unauthorized use or disclosure and to ensure that the records containing the information are protected against unauthorized copying, modification or disposal.”
PIPEDA s.4.7 requires that personal information “shall be protected by security safeguards appropriate to the sensitivity of the information. The security safeguards shall protect personal information against loss or theft, as well as unauthorized access, disclosure, copying, use, or modification. Organizations shall protect personal information regardless of the format in which it is held. The nature of the safeguards will vary depending on the sensitivity of the information that has been collected, the amount, distribution, and format of the information, and the method of storage. More sensitive information should be safeguarded by a higher level of protection.” PIPEDA gets a tad more specific, citing physical, organizational and technical methods of protection as requirements along of mandatory training.
FIPPA s.60 empowers the Lieutenant Governor in Council to set “standards for and requiring administrative, technical and physical safeguards to ensure the security and confidentiality of records and personal information under the control of institutions.” M/FIPPA s.47.1 contains a similar clause.
In other words … it’s for the professionals to decide. Your local privacy expert should absolutely be involved in the discussion, because information classification can be tricky and not all personal information or personal health information is automatically low or high sensitivity. Here’s a few examples: my phone number could be highly sensitive data if I’m in the witness protection program. If it’s attached to my medical records, it could be less sensitive. If it’s a cell phone number, perhaps it is low sensitivity because it’s a burner phone that is not connected in any way to my identity.
BB: What is considered reasonable protection?
TAK: Laws aren’t written by technology folks, and nor do we want them to be. Privacy legislation doesn’t set out the specifics of what is ‘reasonable’ because the law is intended to be fluid and subject to contextual interpretation. Here’s a best practice to follow for a service provider. Work with the client to identify what data you’re going to collect, use and / or process on the data subjects (e.g. the people at the other end of the system). Once you’ve got a complete list, work with clients to understand how they’ll be using the data in the system (business processes, data flows). Take all that information to your security expert, and work with them to identify the appropriate level of information classification / sensitivity for the data. There are very well established information management practices that are associated with those classifications and then you can make a decision about what the client needs and what they can afford. Document that process, and you’ll likely have a defensible position if – or when – the regulatory body comes calling and asks if you took reasonable steps to protect the data subject.
BB: Let’s be honest, few organizations truly understand the classification of their data. Is there some general advice that could be applied?
TAK: If data sets cannot be classified then they should all be treated as information at the highest sensitivity level. While security professionals will often differ on what they believe are appropriate safeguards, I believe it is safe to say that data encryption is a good start. This can be used to protect data in transit and data in storage. As mentioned above, you need to demonstrate that you took reasonable steps to protect the data subject.
BB: How can this be achieved in cloud?
TAK: Trust. The legislation requires each organization to develop a simpatico relationship with all the other companies and service providers because the responsibility is attached to the data. In other words, if you outsource backups, make sure that the organization you’re using is aware of the requirements under PIPEDA, PHIPA, FIPPA and / or M/FIPPA – and get them written down in a contract or SLA.
BB: What about British Columbia?
TAK: In response to concerns about the US Patriot Act in the early 2000s, the British Columbia Government passed an Amendment Act. Under this Act, any organization providing services to the Government – or a public agency of any kind – was also subject to the existing provincial privacy legislation. In addition, the service provider was required to ensure that all storage and access to personal information was restricted to Canada. In other words, any non-Canadian companies must establish facilities in Canada (not necessarily British Columbia) to provide services to public bodies as of 2004. There are also restrictions limiting the purpose for disclosure of data outside Canada, and mandatory reporting requirements.
There’s a lot of reasons why this restriction is difficult, not the least of which are existing programs for sharing data between the US and Canada, e.g. SWIFT. However, for organizations supporting public bodies in BC this restriction remains in place.
The public sector needs a cloud ice breaker
We are still in the early days of cloud adoption. Organizations may not have a regulatory reason that prevents them from using cloud services, but they still need to build trust. They also still need to put reasonable effort into protecting the information they collect.
With so few organizations having properly classified data, that means protecting all of it. From the public sector organizations that I’ve spoken with, many do understand that there isn’t a regulatory reason for them not to keep data in the cloud, but until there is precedent set and a better industry understanding of what defines “reasonable protection”, many are reluctant to break the new ground. As a tax payer and proponent of security and privacy, I’d personally like to see more public organizations taking advantage of the cost savings of cloud services and leverage strong encryption to protect the data.
In a lot of cases, regardless of the data residency, this will do more to protect the data than is done today, and will benefit us all.
