Comments (0)

PRS – Privacy, Residency, and Security

Great. Another TLA. Why do we need another TLA? As it turns out, we’ve been skirting around this one for some time, and now that solutions are starting to emerge, it’s time to brand it. I’m talking about the emerging market for cloud data governance solutions specifically addressing data Privacy, Residency, and Security – PRS.

(Yeah, we coined it. Somebody had to. In all of our discussions with customers, partners, analysts and the like, it got tiresome explaining what we did in large paragraphs. If you have a better one, please share!)

What it means

Privacy. So you want to adopt a cloud solution, perhaps a CRM, ERP, or HR solution (there are those pesky acronyms again!). There’s just one problem (typically, there are more, but for illustrative purposes we’ll pretend this is it) – you’ve been told by your CIO, CSO, CPO - or whoever is ultimately responsible for controlling who is allowed to see what data under what circumstances - that you can’t. Adopt the cloud application, that is. The explanation is that, by placing some sensitive pieces of information into the cloud, you will have violated some regulatory compliance requirement, industry standard, or internal guideline. If violated, as one executive said to me, somebody gets to wear the orange jumpsuit.

Residency. Let’s say you are a bank. (If you have teenage kids, you can really relate to this one!). You’re a bank, however, in a jurisdiction that has passed laws stating unequivocally that any customer-related information must stay within the jurisdiction. This isn’t so far fetched. There are a lot of these jurisdictions, as it turns out, and legislation that applies to a plurality of sectors (financial services, health care, and public sector to name a few). Certain types of information may even have to stay behind the enterprise firewall, or may even have to stay within the department. Where the data physically lives is very different from who is allowed to see it, although location is sometimes used to manifest accessibility. In the end, unless your cloud application is in your jurisdiction, you cannot adopt it. (I’m sure every cloud application vendor has had a potential customer ask the question “when are you putting up an instance in my country?”).

Security. This is the big one. Security means different things to different people. While the majority of security discussions center around the physical accessibility of the data as it resides with the cloud provider, we can also talk about the security between the user’s fingers and the cloud provider’s firewall. That entire path needs to be secured to some arbitrary standards based on your enterprise guidelines. But that’s not all. Not by a long shot. We’ve all heard of insider threats, external hacker threats, and the like. Cloud can make it easier to get your data without your permission. Phishing, key logging – select the information gathering technique of your choice. Now go home and get the data. Insiders don’t even need to be inside anymore. They can hack in their jammies with the rest of the bad guys! Sounds easy? It is! So easy, in fact, that a number of the more prominent cloud vendors have had to implement very specific internal policies and guidelines to prevent their own administrator accounts from being phished, never mind all of the user accounts out there. The bad guys are apparently clapping their hands with glee, as they no longer have to attack each company individually. Now they can set their sites on the cloud vendor du jour, and hack away. One score gets them hundreds, if not thousands, of company hacks for the price of one. Imagine the wealth of identity theft information that awaits!

We care because…?

If you want to adopt a cloud application, you care. Addressing PRS should be a crucial part of your cloud adoption process. Your organization probably has years, if not decades, of enterprise data governance policies, procedures, and guidelines in place. Everything up and down the enterprise architecture stack has a corresponding governance aspect to it. If you go cloud, you need to ensure that those decades of governance are not suddenly kicked to the curb, with the hopes that the cloud vendor has already thought of it for you. The reality is, you need to marry your governance to their governance, with the Internet acting as one big DMZ between you.

It turns out there are four types of cloud users/adopters out there being impacted by PRS considerations;

New users. These are the folks that are adopting a cloud application for the first time. (It may not be their first cloud application, however). Depending on the organization requirements, sector, jurisdiction, internal policies, procedures, and guidelines, the PRS discussion needs to be had up front to ensure adoption can be accomplished without putting the organization in some form of liability or jeopardy.

Existing users. With the rapid growth of cloud computing, a number of organizations jumped in feet first. The whole model of subscription-based pricing for a number of SaaS solutions made it trivial for someone to use their credit card to get subscriptions for their departments or groups. IT, in some cases, never even knew. But they will. And when they do, there are three courses of action;

1. Limited functionality. Since some sensitive information cannot be in the cloud, some users are functionally limited in what they can do with their cloud application. Functionality predicated on sensitive information is made inaccessible. The users cannot realize the full benefits or business value of the cloud application as a result.
2. Limited number of users. Like (1), some users may not be able to use the cloud application because their specific information is sensitive in nature relative to other users, and must stay at home. If the organization wants to consolidate a particular function like CRM or ERP into the cloud, then they need to sort out normalizing everyone’s PRS requirements.
3. Existing users who IT just caught up with. It happens. A particular group or line of business suddenly finds out (typically after some form of governance audit) that they should never have started using the cloud application. The data out there is too sensitive in nature, and violates all sorts of governance requirements. Repatriate the application on premise seems like the only alternative.

So where do we go from here?

In a future blog we will take a different perspective into all of this and discuss PRS and the legal ramifications of having your data in two or more jurisdictions at the same time. (Good Kirk, evil Kirk ?).

Do you have a “PRS moment” you can share? I’d love to hear what cloud adoption experiences are out there.