Making the move to public clouds can seem like a Sisyphean task for many financial and healthcare organizations. Beyond covering the usual bases that are involved in the process, they face a set of regulatory requirements that can make migration feel more risky than it is.
If the cloud used to stand as a taboo for regulated industries, threatening to embarrass any company foolhardy enough to join the rest of the industry in modernity, there is a sense now that those days have passed. Thankfully, we are already seeing a number of big name firms setting out to bring their infrastructure to public clouds.
Already back at the AWS Summit in 2014, McKesson announced that they had built a secure, HIPAA compliant platform running on AWS. Similarly that year, the FDA actively adopted cloud computing for handling some of their workloads.
The most surprising group to come out as ready to embrace the cloud is the banks. A report published by Deutsche Bank last year indicates that even the slow-moving and highly regulated banking sector is adopting public cloud computing, and it is expected that some 30% of the banking industry’s computing workload will be powered by servers operated by public cloud providers within the next three years.
Taking the decision to move to cloud is not an easy one for these industries that bear the responsibilities for their customers’ data. They are held to a (supposedly) higher standard for maintaining security and integrity, and can find themselves with plenty of egg on their face if they are compromised. For reference, see the fallout from the Equifax hack. With the EU’s General Data Protection Regulation (GDPR) regime that will lay out codified standards for the industry set to hit in May next year, you can bet that there are a fair amount of companies going over their practices to make sure that they are in line with the new policies or risk losing their access to business on the Continent.
With these requirements in mind, here are some of the main challenges to cloud migration in a regulated environment that you should consider, the practical solutions to overcome them successfully while comfortably staying within the bounds of regulations, and some reassurances that migrating to the cloud is more than worth it.
Regulated industries like banks, insurance companies, and healthcare organizations are traditionally built on closed networks that rely on legacy applications. Many of these apps may be behind the times, but they meet the regulatory standards and therefore have survived.
However, many of the major players in these organizations are realizing that in order to stay competitive, they need to make the leap to the cloud and start utilizing SaaS applications that sit on the cloud. This of course presents a headache to many security managers and C-level personnel who are adverse to risk, and require a high level of benefits and assurances in order to make the move.
Scalability, and the accompanying flexibility, is one of the primary reasons for moving to a cloud environment. Need more capacity for a specific project? Just add it on and then cut back when you no longer need it, keeping your costs to a minimum and lowering conflicts between the CTO and CFO.
By tapping into the infrastructure of a giant like Microsoft’s Azure or AWS, your company is outsourcing with some of the most mature service providers in the technology business. This shines out in their proven SLA levels that gives you faster access to your SaaS applications than if you were to deploy them on-prem, not to mention that implementation is light years faster.
From the security angle, by working with these big cloud services, you gain access to their professional teams that frankly are probably better at this than your company’s security team. The handling of security patches, operating system hardening, and monitoring and incident response are all on them, leaving your crew to focus on your company’s more pressing needs.
The biggest challenge of migrating your applications to the cloud in a regulated environment is convincing the regulator that it’s a wise decision for the company and not a risk.
The regulator will want to see the risk management process you’ve done so far and the plan you have in place to protect sensitive data stored or processed on the public cloud. They’ll also want to make sure that you’re auditing your data and infrastructure in the public cloud environment (and don’t forget the procedures of handling security incidents in the cloud).
When you’re dealing with sensitive customer data, always prepare for the worst. You need to be ready to act when there’s an external hacker, improper configuration, a rogue administrator on the cloud provider’s network, or even a subpoena revealing sensitive information.
The good news is that you can prevent and mitigate all of these potential crises if you plan the implementation of your public cloud properly.
Before considering SaaS application deployment, we strongly recommended that you sit down with your legal and compliance managers in order to get a better understanding of the relevant laws and regulations of your industry. You’ll also need to research the guidelines and best practices for utilizing public cloud services, and make initial plans for which services you’ll use during your deployment.
Here are some resources to help you gather information:
Encryption is the cornerstone around which proper data protection is built. When done right, it leaves attackers with an unintelligible soup to contend with, hopefully ruining their day and not yours.
Thankfully over the past year or two, encryption in transit (using HTTPS for the entirety of traffic between the browser and the SaaS application) has become a standard for all major SaaS applications. The tricky part comes when you look to implement encryption at rest for your SaaS solutions, because the SaaS application can’t really be blind to the encrypted data.
There are two approaches to encryption at rest that we suggest to satisfy your regulator while also keeping customer data private from prying eyes:
Examples of vendors: Vaultive, CipherCloud, and eperi
In addition to encryption, make sure that you implement strong authentication methods (like two-factor authentication) and proper backups and verification of backup sets to avoid corruption or accidental deletion of your data.
According to the “shared responsibility model,” using SaaS, the customer is responsible for data classification and accountability (i.e., defining data sensitivity as confidential, secret, public, etc.), and performing an audit of who has accessed the data. The two common approaches for auditing are:
When you review audit capabilities, don’t limit the audit to access from your organization’s employees, but also include actions performed by the SaaS vendor employees.
When you’re considering migration of critical business applications to the cloud, make sure you fully understand how your ability to access and run those applications affects your capacity to provide service to your customers. For example, think of a bank or credit card organization being unable to provide financial transactions. Not an enviable position to be in.
To mitigate the risk of losing connectivity, make sure that you know the location of the data centers that are hosting your data. Usually, the locations are in different countries on the same continent, balancing between the need for proximity with the precaution of preparing for national level issues. Make sure that you understand and track data privacy laws where your data is stored, verifying that they meet your regulatory and internal requirements.
Once you know your data is synced between two data centers (primary and disaster recovery site), it’s time to negotiate with the SaaS vendor the recovery time—such as RTO (Recovery Time Objective) and RPO (Recovery Point Objective)—that defines how much downtime your organization can suffer before getting into a critical phase (leading, sometimes, to you going out of business).
The final thing you should check is the exit point. Make sure the contract with the SaaS vendor allows you to end the contract without paying the SaaS vendor for the unused time on the cloud service.
Additionally, make sure the contract specifically states that the SaaS vendor must allow you to export your customers’ data stored in the cloud and to your on-premises network. Make sure that once your customers’ data has been exported from the SaaS application, the SaaS vendor agrees to erase your data (including backups kept on the cloud) after the contract has ended.
Even though migrating systems to the cloud is challenging in a regulated environment with sensitive customer data, it’s possible for you to get the regulators’ approval as long as you perform adequate risk management, map all the risks relating to the cloud environment, and set relevant controls.
If your organization would like to be ahead of your competitors, rapidly adapting to new technologies and providing better service to your customers is critical. The benefits of using SaaS applications powered by a reliable public cloud provider are numerous, and they’ll definitely pay off in the future. In addition to the practical advice given in this blog post, be sure to catch up on compliance documentation provided by AWS, Azure, and Google Cloud Platform before you start drawing up your blueprints.
Once you have the answers to all of the potential drawbacks and solutions for presented challenges, you’ll be ready to face the regulator and senior management and take your first step into the cloud era.