Compliance is now global because the cloud is global

While HIPAA is a famous American regulation, the challenge of compliance on the cloud is global. New global business models spurred by cloud adoption also refer to the digital connections across countries and continents. More than ever, digital businesses operate in a global market, which means the more restrictive policies do cross international borders.

Let’s break it down by examining a simple map of regimes to consider as a cloud-based company.

This is just a small collection of compliance regimes. There are more, but it’s the main collection of regimes that matter to cloud companies. In fact, these are pulled from the Business Associate Agreement documentation from AWS and Microsoft Azure, meaning if they support these regimes, then you should do, and if they don’t, then the regime isn’t that important yet.

A business obviously can’t tackle all these regimes from the start, so the best strategy is to focus on the ones that matter first. For example, as digital health company located in the United States serving a U.S. market, HIPAA is critical. From there, GDPR, SOC, and perhaps GxP are important.

Being compliant with as many regimes as possible across borders really only scales with the business itself. For example, multi-national pharmaceutical companies whose market is essentially the entire world population will need to have a much stronger cross-border compliance management program than a hospital located in Milwaukee, Wisconsin.

The interesting shift compared to years past is that the cloud itself is inherently making business models more global. The ease of the cloud to serve international markets means compliance is increasingly becoming an international concern for companies. Because addressable markets are international, the scope of potential types of sensitive data that could be collected is larger, thus making compliance in that particular geography an unintended necessity.

GDPR as an example of compliance crossing borders

Some Standards Developing Organizations (SDOs) are national, like NIST in the United States, while some are international, like ISO, but due to the global nature of compliance, national ones like NIST are increasingly receiving broad acceptance internationally. Both perform the same function — setting standards and guidelines — but where and how the output from these organizations is applied can vary based on geography. For example, the standards set by NIST are not immediately applicable in Australia, but the Australian Cyber Security Centre (ACSC) tapped work put forth by ISO/IEC when creating its Information Security Registered Assessors Program (IRAP). The standards which come from these organizations are thusly national while pulling from international inspiration. In many ways, the global nature of an organization is an advantage since its standards can lend more of a “one-and-done” approach.

Most regulations are inherently national because they come from a governing authority. As an example, HIPAA does not inherently apply outside the United States. However, regulations are increasingly crossing borders. Taking HIPAA as an example, Covered Entities can be global while many digitally-based Business Associates are increasingly located international as well. A simple example is the use of data centers in Asia.
One of the best examples can be found in Europe with the General Data Protection Regulation (GDPR). This much-anticipated new European Union security and privacy regime went into effect on May 25, 2018. GDPR leaves some discretion to EU member states, but, as a general rule, applies to any company dealing with the personal data of EU citizens.

GDPR sets clear guidelines that strictly protect the privacy of individuals across industries, with some distinctions. For example, within healthcare, GDPR explicitly applies to physical and mental health data, genetic data, and biometric data. That data can only be accessed (1) with specific consent from the individual, (2) for health and social care, or (3) for public health (such as cross-border containment of an infectious disease).

Strict requirements also exist for reporting a security breach within 72 hours from becoming aware of it. In the United States, any organization would have breach reporting timelines in its policies and contracts, but most breach reporting timelines stipulated by major cloud providers and vendors are much longer: days, weeks, or even months.

Some of the more challenging components of GDPR are centered on the rights of individuals to obtain access to all of their data or the right to be forgotten, meaning the right to have all personally identifiable information (PII) data deleted. The complexity of this specific regulation cannot be understated since the specialty of PII per respective industry changes how and where data is managed. Granting access to all personal health data or being able to delete all health data is a high bar to meet, especially for large, bloated electronic health records and legacy healthcare software.

One important contribution of GDPR is the overarching principle of data protection by design and default. Sadly, security and compliance are often an afterthought at best or perceived as an unnecessary box to check at worst. GDPR explicitly attempts to resolve this pattern by anchoring risk assessment, analysis, and management to the entire lifecycle of products and services to ensure data is protected and secure.

GDPR doesn’t mess around. Penalties for violations can be as high as 20 million euros or 4% of global revenue, whichever is greater. Given the practicality of the regulation, legal precedent can only be determined with ensuing years. Legal interpretation turns GDPR from a physical European liability to a conceptually global one. Ironically, global regulations like GDPR, as opposed to global organizations and standards, pose more liability threat considering more permutations of risk exist.

So why does such a burdensome compliance regime even stand?

GDPR is a direct result of frustration by the European Union (EU) with Google, and other companies like Google, that over the past ten years have had multi-billion dollar antitrust style lawsuits from the EU because European culture doesn’t tolerate private companies having so much insight and data on its citizens, and that Europeans don’t have any control. Generally speaking, the EU and its citizens believe government has a duty to protect and control this data.

When Google played hardball, the EU updated the Data Protection Directive, a 1995 regulation that more explicitly protects the rights of its citizens in today’s internet age. In no way is GDPR proactive; it is reactive regulation.

With some irony, compliance and regulation have only helped cement the incumbents and the monopoly. It’s no wonder that technology titans like Mark Zuckerberg, Facebook’s founder and CEO, say Yes please, regulate me. Zuckerberg understands that if regulators say organizations can’t let data in or out of the house, the organizations that have all the data win.

Compliance can also be considered mushy since it can’t be viewed as black or white. Decisions about compliance are not necessarily binary, technical questions that can be clearly measured. The final stage of compliance is a matter of legal precedent, which for GDPR none yet exist.

With a fine that can reach four percent of global revenue, no organization wants to be the first to set that legal precedent. How will fines be enforced? How are bad actors identified? The risk of not complying is too great, so business organizations will comply.

Start with an international perspective

It’s a challenge to manage the variability of global compliance. A cloud-based business operating in a global economy is inherently required to deploy a global compliance management program.

The best strategy begins with the business understanding it will inherently serve a global market, and work backwards from there, identifying the appropriate regimes that matter.