Many people associate client data protection (CDP) with large global transactions. Outsourcing-related deals in all likelihood contemplate some form of access to and transmission of, and possibly the retention, storage, and/or destruction of client data. But it is also true that if you have resources (people) supporting your projects from oversees (Europe or India) or you have servers outside the jurisdiction in which services are being delivered, you need to think about whether there are contractual provisions in place and laws that apply to you with regard to data (be it personal, health, relating to children, etc.) that isn’t yours.
We would all like to think — but of course know better — that there are guarantees and certainties in the world of IT. As we all know, this is not the case — even as it relates to the most sophisticated companies globally. By way of example, most recently, hackers breached Sony Corp.’s PlayStation Network and Qriocity services security and made off with the personal information of its worldwide user base. I happened to be in India at the time, and the front of the paper in Mumbai had a picture of three Sony executives bowing in apology to Sony customers. I think I can safely say this is the sort of thing that would keep lawyers and business executives up at night.
As many of you already know, one party in the relationship is going to be the data “controller” or “data exporter” and the other, or others, the “processor,” “data importer,” or “sub-processor” or processors. The processor is the party providing services and to whom the data is sent, while the controller is the party collecting the data and providing it to the processor. The law treats each of these parties differently, as do the provisions relating to the same that inhabit the contracts the parties execute.
For example, one of the statutory obligations that could apply to a transaction of personal data of EU and European Economic Area citizens is the requirement that affected parties enter into the “EU Model Clauses.” These model clauses speak to the transmission of data to a third country, so if you are a Canadian company providing services to a client in the EU or in a country in the EEA and you decide to use your resources based in India to support the development of the product or to provide services, consider that while Canadian privacy laws have been found to be in line with European ones, the laws in India have not. So these model clauses would need to be executed between the EU and India-based entities.
The key thing to remember is that in addition to any other laws that might be applicable; law that applies to personal data is the law of the country in which the person about whom the information relates resides. So if I lived in London, England, and my personal information was provided by me to my bank, and that bank had outsourced certain finance-related services to a third party in Canada using support services in India, the bank in England would be required to enter into the EU Model Clauses with the local affiliate in India of the company based in Canada.
There is a reason why there are CDP-specific subject matter experts in this area, and I certainly don’t profess to be one of them. As a transactional lawyer though, these issues arise with increasing frequency and it is essential they be managed appropriately because otherwise the consequences, not just financial, can be significant indeed.
So what are some of the things your client as data controller or processor should consider?
1. Do you know what type of data is in your control or that you are processing?
• Type: Is it personal? Medical? Does it relate to a child? Is it none of these?
• Entity: Are you in the public sector, either in Ontario or federally? Or in the private sector?
• Law(s) that apply: Do you know which laws apply domestically or internationally?
• How much: Are you getting more information than is necessary to service your end-users (controller) or to do the job (processor)?
• Level of access: The default in your system is likely full access — and more than likely, it shouldn’t be.
2. Whether you are the data controller or the data processor, ask yourself: why, by whom, what for, where, and when. Depending on how you answer these questions, can you justify access?
3. “System of least privilege”: According to this principle, the least access necessary to perform the job should be provided.
4. “System of segregation of duties”: It has been said that it takes at least two people to commit fraud, so the way this principle works, for example, is to set up security measures so that changes to a system can only be made in the production environment, and not in the live environment.
5. Consent and controls: If you are the data controller — make sure you have consent to disclose if the law requires you to. Identify the type of data being processed and tell your processors what protocols they need to put into place to protect the data. The data processor will have certain statutory obligations, but they may not be nearly as onerous as those on the data controller, and the contracts should be clear about who is playing which role and where the responsibilities and liability/indemnity obligations lie.
6. What is reasonable? Has the data controller provided you with the protocols you need to put into place? Whether or not the data controller provides you with information regarding the data and the controls that you need to put into place as the data process, the default to keep in mind is “What would be reasonable in the circumstances?” in terms of putting in place your own internal controls. Ask yourself: What are the relevant industry standards?
7. Contracts: Personal information is not the same as confidential information and should not be dropped into the same bucket. Privacy laws are not the same worldwide and due care needs to be taken in ensuring the obligations of each party are clearly defined, that risk is appropriately allocated, and that indemnification is available as a remedy for failure to comply.
This is all written from the perspective of the private sector; however, these principles are no less important or relevant to the public sector. The laws are not necessarily the same, and the obligations incumbent upon each may be quite different, so it is essential to consult with counsel and CDP subject matter experts early on in the process so that risk regarding the protection of data can be mitigated.
Sarah Dale-Harris is corporate counsel at Accenture Inc. and can be reached at [email protected] or at 416-641-3151. There are numerous laws applicable to privacy and the protection of personal information — too numerous to link to in this column — so any links provided are examples only and are not an exhaustive list. Information regarding privacy laws in Canada can be found on sites such as the Office of the Privacy Commissioner of Canada. The opinions expressed in this article are those of the author alone.
We would all like to think — but of course know better — that there are guarantees and certainties in the world of IT. As we all know, this is not the case — even as it relates to the most sophisticated companies globally. By way of example, most recently, hackers breached Sony Corp.’s PlayStation Network and Qriocity services security and made off with the personal information of its worldwide user base. I happened to be in India at the time, and the front of the paper in Mumbai had a picture of three Sony executives bowing in apology to Sony customers. I think I can safely say this is the sort of thing that would keep lawyers and business executives up at night.
As many of you already know, one party in the relationship is going to be the data “controller” or “data exporter” and the other, or others, the “processor,” “data importer,” or “sub-processor” or processors. The processor is the party providing services and to whom the data is sent, while the controller is the party collecting the data and providing it to the processor. The law treats each of these parties differently, as do the provisions relating to the same that inhabit the contracts the parties execute.
For example, one of the statutory obligations that could apply to a transaction of personal data of EU and European Economic Area citizens is the requirement that affected parties enter into the “EU Model Clauses.” These model clauses speak to the transmission of data to a third country, so if you are a Canadian company providing services to a client in the EU or in a country in the EEA and you decide to use your resources based in India to support the development of the product or to provide services, consider that while Canadian privacy laws have been found to be in line with European ones, the laws in India have not. So these model clauses would need to be executed between the EU and India-based entities.
The key thing to remember is that in addition to any other laws that might be applicable; law that applies to personal data is the law of the country in which the person about whom the information relates resides. So if I lived in London, England, and my personal information was provided by me to my bank, and that bank had outsourced certain finance-related services to a third party in Canada using support services in India, the bank in England would be required to enter into the EU Model Clauses with the local affiliate in India of the company based in Canada.
There is a reason why there are CDP-specific subject matter experts in this area, and I certainly don’t profess to be one of them. As a transactional lawyer though, these issues arise with increasing frequency and it is essential they be managed appropriately because otherwise the consequences, not just financial, can be significant indeed.
So what are some of the things your client as data controller or processor should consider?
1. Do you know what type of data is in your control or that you are processing?
• Type: Is it personal? Medical? Does it relate to a child? Is it none of these?
• Entity: Are you in the public sector, either in Ontario or federally? Or in the private sector?
• Law(s) that apply: Do you know which laws apply domestically or internationally?
• How much: Are you getting more information than is necessary to service your end-users (controller) or to do the job (processor)?
• Level of access: The default in your system is likely full access — and more than likely, it shouldn’t be.
2. Whether you are the data controller or the data processor, ask yourself: why, by whom, what for, where, and when. Depending on how you answer these questions, can you justify access?
3. “System of least privilege”: According to this principle, the least access necessary to perform the job should be provided.
4. “System of segregation of duties”: It has been said that it takes at least two people to commit fraud, so the way this principle works, for example, is to set up security measures so that changes to a system can only be made in the production environment, and not in the live environment.
5. Consent and controls: If you are the data controller — make sure you have consent to disclose if the law requires you to. Identify the type of data being processed and tell your processors what protocols they need to put into place to protect the data. The data processor will have certain statutory obligations, but they may not be nearly as onerous as those on the data controller, and the contracts should be clear about who is playing which role and where the responsibilities and liability/indemnity obligations lie.
6. What is reasonable? Has the data controller provided you with the protocols you need to put into place? Whether or not the data controller provides you with information regarding the data and the controls that you need to put into place as the data process, the default to keep in mind is “What would be reasonable in the circumstances?” in terms of putting in place your own internal controls. Ask yourself: What are the relevant industry standards?
7. Contracts: Personal information is not the same as confidential information and should not be dropped into the same bucket. Privacy laws are not the same worldwide and due care needs to be taken in ensuring the obligations of each party are clearly defined, that risk is appropriately allocated, and that indemnification is available as a remedy for failure to comply.
This is all written from the perspective of the private sector; however, these principles are no less important or relevant to the public sector. The laws are not necessarily the same, and the obligations incumbent upon each may be quite different, so it is essential to consult with counsel and CDP subject matter experts early on in the process so that risk regarding the protection of data can be mitigated.
Sarah Dale-Harris is corporate counsel at Accenture Inc. and can be reached at [email protected] or at 416-641-3151. There are numerous laws applicable to privacy and the protection of personal information — too numerous to link to in this column — so any links provided are examples only and are not an exhaustive list. Information regarding privacy laws in Canada can be found on sites such as the Office of the Privacy Commissioner of Canada. The opinions expressed in this article are those of the author alone.
