“What’s our cloud strategy?” is a common question in IT these days. A somewhat lengthy answer is required. Few technologies have grown as fast as the cloud. It is a profound shift to have your data – your precious, regulated data – stored not just out of your control, but out of your sight. This change provokes a wide range of responses, from “Never in a thousand years” to “Take my data, please”. A better reaction might be “Yes, but.” As with many things in life, and certainly in healthcare, the extreme reaction is not the best one. As tempting as a flat Yes or No answer is, there are important questions to ask when moving your data to the cloud:
Questions to Ask
Why are we doing this? Why are you going to the cloud? Save money, save hours, focus on other priorities, improve performance? Make sure that you’re measuring that metric for a few months, before and after the cutover, to determine if the move to the cloud achieved those goals, or if further refinement of the cloud solution is needed to achieve your goals.
Are we starting small enough? Select a system of minor importance for your first try at a cloud solution, to minimize the pain if you make mistakes, or if the cloud just isn’t right for you. One good option is to backup data to an Amazon S3 instance – so long as you run your old backup system in parallel for a while. Any ancillary, internally used, or otherwise small-footprint application is an excellent choice for your first move to the cloud.
How important is flexibility? If you’re doing a lot of customization on a system, or working closely with its users, or doing any technology work where flexibility, fast response, and being on the leading edge is important, don’t send that to the cloud. Just as you get better driving performance with a more difficult manual transmission than an automatic, you get better technology performance with an on-premise system – at the price of more management overhead.
What is our team’s core competence? If your competitive advantage lies in a system, it is better off in-house then in the cloud. But be careful: often, the competitive advantage isn’t “the system” as a whole, but a smaller slice such as “customer service for system users” or “system performance” or “the proprietary data analysis we do on the system”. In those three cases, cloud hosting could very well make sense.
Can we trust these guys? Not all cloud providers are Amazon or Azure. While those two have the money, the people, and the expertise to secure data, “Joe’s House of Hosting” may not be as reliable. The smaller the cloud provider, the more due diligence you need to perform:
Their financials –will they still be in business at the end of the contract?
Their staffing levels – will one or two departures cripple their support team?
How redundant is each of their system’s components?
How mature are their operational procedures, such as policies and documentation, vulnerability scanning, patching, maintenance, configuration management, monitoring, logging, backup, firewall/IDS management, and access control?
Where is my data – in the US, abroad, or “somewhere”? There may be requirements to answer this in a certain way – but regardless, know where your data is.
Who can see my data – just us, us and them, or us, them and their sub-contractors? Any sub-contractor should have equal security to the primary vendor, but this is not often the case.
Who has seen my data – on their end? It’s easy to pull your own logs; make sure that the vendor is maintaining the access records of their own people.
Are they securing the virtual environment? Hopefully they mention, or at least show familiarity with, NIST Special Publication 800-125 “Guide to Security for Full Virtualization Technologies” (an updated version is in draft). They should also routinely disable unused virtual hardware and hypervisor services, and use the hypervisor to monitor the activity between guest OSes.
Is this cloud more secure (but not perfect)? There’s an old Boy Scout joke of how you don’t need to outrun the bear, you just need to outrun the slowest hiker. Similarly, the cloud provider doesn’t have to be perfect, just an improvement on the security and service that your organization can provide. If too many priorities are bogging down your IT team, outsourcing some of them to the cloud can free up time to focus on the remainder.
What will we still have to do? Sadly, you can’t just turn over the keys and walk away from your cloud hosted solution. There’s still housekeeping you may need to do, such as user administration, activity review, patching, or data management or interface monitoring. A good cloud provider focuses on what they do and doesn’t get drawn into side tasks.
What, precisely, will they do? Following from the above, make very clear what is the cloud provider’s responsibility and what is yours. The provider should be able to tell you, in detail, what they will and won’t do. Which leads to…
Do we have everything in writing? Don’t trust verbal commitments - if it’s not in the contract, it doesn’t exist. A good cloud contract will define, at a minimum, the uptime guarantee, the maximum data loss / Recovery Point Objective, the response time for service calls, and what happens in the event of a vendor’s closing, or the contract ending – see below. And, of course, the latest and greatest in Business Associate Agreements.
What if we’re wrong? Never make a decision you can’t undo. There’s many reasons that a cloud solution may be tried and found lacking, and you should be prepared to reverse course. In your contract, make sure there are provisions for data return (to you) and data destruction (for them). Be sure to line up an alternate provider, whether on-premise or with another vendor, of similar services. And see that you retain, or can acquire, the technical expertise to undo your decision.
Trusting someone else with your data is a big step, and can only be justified by big rewards. Simply “moving to the cloud” is liable to cause more problems than it solves. Those rewards can be gained with a thoughtful and vigilant cloud solution, if you do your homework first.