If you’re at all involved with IT, you know that every other article you see these days seems to have something to do with cloud computing. Increasingly, these discussions are turning to the world of science. However, there is one group within this world that has remained fairly resistant to the cloud, and that is the FDA regulated group. Primarily, my familiarity is with the pharmaceutical and device industry, and that is, of course, where I see the most resistance. Typically, there are two major concerns voiced, one of control, and the other of security. I would like to challenge both of these concerns by questioning the underlying assumptions.
The first concern, that of control, is usually voiced as a desire to “know” who can be talked to if something goes wrong. That is, if the data is internal to the organization, you can cause the people charged with safeguarding the data endless amounts of grief if something happens to it. Perhaps (and I think this is the underlying assumption) you could even get them fired if something serious happens. If the people responsible for data safety are external (at, say, Amazon or Google), then you don’t have that sort of power. There are two problems with this perspective. The first has to do with motivation. Assuming that the people doing the job of protecting your data do so out of fear of losing their jobs (which they probably don’t), they are just as likely to lose their jobs for failure to perform at one company as at another. The owner of the data may have less direct impact on that, but realistically, the risk to the data guardian doesn’t really change. The bigger problem is the “so what?” problem. So what if you can get someone fired? Does that get your data back? Does it restore your access if it has gone down? Of course it doesn’t.
The real question needs to be what quality level you can expect from internal vs. external. By quality, I mean not only reliability and safety, but also cost. Let’s be honest, cloud companies typically have a much higher quality of infrastructure available for their data center than do any individual business whose primary job is not providing a data center. If you doubt that, go tour the data center in your company. In this day and age, even small companies can and do have robust data centers. However, compare what you have to what Google has. With a cloud solution, you can access such elaborate technology for a much lower cost than if you were to attempt to do the same yourself. While cloud outages are hardly unknown, are outages involving your internal infrastructure unknown? If you think about it, such outages and service interruptions are probably not that uncommon in your environment. They may not seem as big, as they don’t impact hundreds of thousands of users, but they are likely no less significant to your data and access to it.
In terms of talent available to you, either in a support or perhaps even customization role, you may find that the talent pool available from cloud vendors may be more substantial than what you are able to hire within your company. This may make your data not only more secure, but if you are having things customized or enhanced, you may find yourself more satisfied with the end results.
The other concern is one of security. Typically, this is the fear of the “open system”, by FDA definition (21 CFR 11.3(9)) a system where the access control is not by the same persons responsible for the data itself. Two points need to be made here. The first is that this regulation was written back in the days when there was the internet (still a relatively new phenomenon) and then there were the computers in your company, and the two were generally not connected. Now, when everyone’s internal system is attached to the internet, you may not have nearly as much control over access to your system as you think you might. In other words, you may be safer treating your system as an open system regardless of whether you own the servers or they are located in Googleville. Certainly, if you have employees accessing your data from their homes, you will employ all manner of additional security, and that has become relatively common.
The second point is that the additional requirements for open systems are that you have a means of encrypting data. That is all. Really. In fact, here’s the entire regulation: “Persons who use open systems to
create, modify, maintain, or transmit electronic records shall employ procedures and controls designed to ensure the authenticity, integrity, and, as appropriate, the confidentiality of electronic records from the point of their creation to the point of their receipt. Such procedures and controls shall include those identified in § 11.10, as appropriate, and additional measures such as document encryption and use of appropriate digital signature standards to ensure, as necessary under the circumstances, record authenticity, integrity, and confidentiality.” That is it. Today, encryption technology for transmitting data is as common as that https you’ll occasionally see in the URL bar of your browser. In other words, it isn’t much of a challenge. Otherwise, the same set of rules as for a closed system apply. Therefore, you’ll need to take the same care. You’ll want to audit and evaluate the systems in use by the cloud company, just as you would your internal systems. But there is really nothing additional you’ll need to do.
Now that I’ve said all this, I need to point out that contract terms need to be ironed out. Sometimes large cloud companies have less than ideal guarantees around up time and the like. You’ll also want to be sure that you are comfortable with what happens if the cloud company ceases operations, or you decide to not use them anymore. Where does your data go, and how easy is it for you to get it back? This can be easily overlooked and people can be burned by bad decisions in this area.
What I’m trying to get at with all of this is that we need to clear in the thought processes behind deciding on the cloud. I think to date, many of us have been driven by fear, and fear tends to lead to fuzzy thinking. That won’t get you to where you need to be.