For some customers, that is an absolute must. For example, one forum request in the Spiceworks community says its compliance rules state, "Data owner must maintain complete control over the encryption keys at all times, and no personnel from the cloud service provider should have access to the keys."
Why would admins need or want to control their own keys? Fear of intrusion into organizational privacy is the answer. That fear has been exacerbated by former NSA contract Edward Snowden's spying revelations and the ongoing fights between Apple and the FBI and between Microsoft and the U.S. Justice Department over government access to customer data.
Those U.S. government actions, an effort in the United Kingdom to require government access to nearly all records, similar efforts in other countries, and a series of data breaches at technology providers all have eroded corporate trust that both their customers' and their own privacy is maintained.
According to Holme, BYOK would ensure the customer must also be subpoenaed, not merely the technology provider such as a cloud vendor. Why? Because the vendor doesn't have the key -- only the customer does. "This would ensure that customers are aware when and if their data must be turned over for legal reasons, and in theory would add enough political complexity to reduce the potential of that ever happening," Holme said.
But BYOK is not simple. As my colleague Mary Branscombe has explained, BYOK involves significant effort by the customer to provision and maintain. If you lose those self-provisioned keys, you're in a pickle: Your vendors cannot retrieve what they don't have. Although your vendors cannot give your keys to someone else, they can't give them to you, either.
One approach is to set up a key repository secured by a separate key. Microsoft does that for Windows 10 users via their Microsoft accounts. Apple has long done the same for OS X users with its FileVault encryption service. For enterprise users, Microsoft offers Azure Key Vault, which works with hardware security modules to safeguard your keys in the cloud. Again, you're still working with a single vendor to protect the keys to the data they hold. That may not be what you need.
You might want to transfer that responsibility to another vendor, to make it more complex for someone to get to those keys. For example, you'd have Microsoft hold your data, which is encrypted using keys you create and manage, but a cloud-based service stores copies of those keys in a key repository. Such vendors include CipherCloud and KeyNexus.
Right now, this is a theoretical option for Office 365, since it doesn't yet support BYOK. When it does, you'll have to weigh the value of that added privacy protection against the overhead of achieving it. I know some companies for which the cost will be worthwhile. Maybe it is for you, too.
Sign up for MIS Asia eNewsletters.