My name is Hayden, I’m a partner in HopgoodGanim’s Intellectual Property and Technology Division. HopgoodGanim is a national law firm. My practice generally comprises of advising clients on intellectual property issues both in terms of protection, commercialisation and enforcement.As well as looking at information technology, procurement agreements, licensing, SaaS-based arrangements, and informational privacy risk.
Privacy is always an issue that a lot of people are really concerned about when they think about cloud solutions. I can understand why that is but then some ways it is a risk that can be managed properly, and is done so on a regular basis everyday. So any organisation that has an annual turnover of three million dollars or more generally speaking, will be bound by the Privacy Act and, specifically the Australian Privacy Principles within that Act. They apply to how organisations can collect, use or disclose personal information. Personal information is any information that reasonably identifies an individual or actually identifies an individual- so name and address. It could be an email or it could be a range of things. So of all that if you fall within that revenue threshold, is regulated information under the Privacy Act.
Now, every organisation already has that level of regulation upon them, whether or not dealing with the cloud vendor if they actually made that three million dollar revenue threshold. So already they’ve got that same manner of regulation upon them. I suppose a concern that is sometimes spoken about when we talk about cloud based solutions, as well, is the fact that you’re giving away physical control of that data to someone else to manage. So there’s a loss of physical control and that I guess comes with it an initial concern. But it’s a concern that can be managed legally and technically. And I say that because the contract itself with any cloud contract should get proper rights to access data to the clients still maintains legal control of that data, so they can get in and access that, and they can take backup copies as they wish. They retain control of it however, if they want they can go in and get it. At the end of the arrangement, there should be contractual arrangements in the contract to facilitate transitioning away from the current cloud provider, maybe to someone else so that’s another way of managing it.
On top of that, another issue that’s often spoken about in the context of privacy is things like data sovereignty. So in other words, if I give my personal information of my customer data to a cloud provider, will they put it in some strange, obscure jurisdiction with really weak privacy laws? And then I’m going to be under the gun from the regulator? And that’s a valid concern because the Australian Privacy Act does regulate how you disclose personal information outside of Australia. But the simplest way to resolve that is to just agree with cloud providers who host their data within Australia. So that’s the easiest and quickest way to resolve it.
A lot of cloud providers are open to working with infrastructure that’s hosted in Australia. And even if you do move it outside of Australia, well there’s ways you can still manage it. You can get customer consents, you can lock it to a specific jurisdiction; which you can undertake a legal analysis and form a view that it does have laws in place which are reasonably equivalent to the Australian Privacy Act. There’s a whole lot of ways you can do it. There’s no, I guess strict impediment under the Privacy Act to using cloud services. It’s all a matter of engaging in a proper dialogue of making sure the contract has the rights necessary to give the customer effective control of the data.
So Service Level Agreement (SLA) is generally sort of an adjunct to the main contract that you enter into with the service provider or vendor. It generally describes things like how quick a vendor might respond to a service desk issue. You know, maybe that issue might be a really minor thing in which case the response time might be ‘X’ amount of hours or days. Or if it’s a really critical issue, the SLA categorises it based on certain tests. If it’s a critical issue well the overall response time might be more quick. So it’s all about contractual promises around how you will deliver the service on a day to day basis. How you respond to problems, and how often I guess the solution is accessible to the users.
So for instance, in a hosted software application, there might be down time. That down time might be due to scheduled maintenance or something like that. So that’s understandable, all software applications need to be subject to routine maintenance from time to time. But also there might be extraordinary events sometimes, which cause the application to be down in an unanticipated way. So the Service Level Agreement will give the customers some confidence to say that for instance, we contractually agree to a service level that the software application will be available 99.999% of time or something like that. You probably would have seen obligations like that in Service Level Agreements before. And there’s no real limitation as to how you can draft the Service Level Agreement. If the customer has a particular requirement around how the service needs to operate that can be reflected in the agreement, provided that it’s technically and commercially feasible for the vendor, there’s no reason why it can’t be done. There’s no such thing as a one size fits all Service Level Agreement.