I wish I was a pirate.
You know, sailing on the open seas, parrot on my shoulder, bottle of Jamaican rum in one hand and a treasure map in the other. That would be the life.
That treasure map would be my pride and joy–the key to my happiness and success. It would give me confidence and security because I know that at any time, I can sail to my treasure, collect it and head off into the sunset.
This is how I feel about the corporate information I store in the cloud–safe because I know my information is securely locked away, ready and waiting for when I need it.
So, why am I constantly worried?
Well, as a pirate, someone might steal the map. I might lose it. Someone might even find my treasure by chance–and I know that Blackbeard is constantly trying to figure out where I’ve hidden it so he can steal the lot.
But we all know I’m not a real pirate. That said, with my corporate hat on, there are some interesting parallels between the tale of my stolen treasure and my content in the cloud.
A lot of organizations store content and systems in the cloud without really knowing where those vitals corporate assets are being put–a bit like me as a pirate, giving all my treasure to my crew and asking them to bury it for me. My crew might be genuine and store that treasure securely, and draw me an accurate map so that I can get my hands on it when I want. But on the other hand, they could just be a bunch of pirates, running an insecure storage facility, using outdated treasure chests, liable to go bust at any stage and get rid of the treasure to their peers on PirateBay!
The moral of my pirate tale? If you are using cloud services, you need to know where your content is – and any decent cloud provider should be happy to tell you.
If your organization is based outside of the US or has non-US elements there are very good legal reasons for this. There are a number of laws and regulations around the globe that stipulate where an organization’s data and information can and can’t be stored. For example, the European Union (EU) Directive on Data Protection that came into effect in 1998 requires all EU-based organizations to store any personal content within the EU. The US-EU Safe Harbor agreement eased the situation slightly by creating a provision for EU companies to store content in US data-centers, but given that this is a self-certification scheme, many EU-based organizations are still wary of committing to this.
Furthermore, three specific European countries, Germany, Switzerland and Austria, have extended the EU Directive to force data storage to remain within the specific country in which it was created – namely German data must remain in Germany and so on.
This means that European organizations simply cannot commit to cloud providers without asking some very specific questions about where cloud data is to be based. However, in my opinion, the principle should be applied as a best practice across the cloud world.
With regards to actually asking the question, the ideal time is during initial sales conversations. Subject to a suitable answer, this would flow directly into the creation of a custom Service Level Agreement (SLA) to be associated with any corporate cloud usage. This SLA should not only define where any primary data centers are based, but also determine how and where backups of this data will reside – it’s not enough to compliantly store the primary data for an organization in Germany if the backups are stored in Tokyo.
In addition, the SLA should cover basic, but vital, elements (a good description of which are here) such as expected uptime, access and security mechanisms, disaster recovery procedures and timings should anything go wrong as well as penalties for failing to comply with the SLA by either party.
Finally, the SLA should detail exactly what happens at the end of the agreement. Many organizations enter into cloud contracts without thinking that they will ever want to end the contract–but the reality of business is that systems, staff, standards, procedures and more change. Therefore, at some stage it is likely that the data stored in the cloud service will need to be moved from the incumbent cloud provider to somewhere else. Some organizations have been hit with massive technical and project management difficulties moving content from heavily restricted servers and systems into new on-premises or cloud-based facilities. Far be it for me to say that the existing providers were being difficult on purpose–but the substantial service invoices raised for items such as “technical support” and “migration services” at the end of such contracts may suggest that there are still some pirates out there.
So, before I head back out onto the open seas of cloud management, remember this–if you’re going to bury your corporate treasure somewhere, make sure you know where you put it.
Read other posts by David Jones
[This post originally appeared on the Hyland blog and is republished with permission.]