I saw an article the other day and it was titled – The Do’s and Don’ts of Safeguarding Cloud-based Data with Encryption – and it got me thinking…
As many of you know, I spend a lot of time talking to SaaS providers and one thing is for sure – they are all worried about Data Protection and Privacy in the Cloud. When thinking about the move to the cloud, one of the biggest stumbling blocks for our Application Partners is the risk that the data will be exposed or accessed by someone that should not have access to it. A lot of our partners’ application data is sensitive—whether it contains patient data, credit card data, financial data or personal HR data records—so it is very important that they keep control over the potential of unintended data exposure.
One way people in IT talk about protecting data is with encryption, and the article I was reading also recommended using an encryption algorithm to encode the data. So then I asked myself—why is it that less than 15% of our SaaS partners are using our Transparent Data Encryption capability to protect their data? The only answer I could come up with is that, not unlike the fact that all of us that pay for INSURANCE (car, health, home flood, etc.), we HOPE that we will never actually need it. We hate paying for it, but we like having it IF something happens. That is how most of our customers/partners feel about Data Encryption. They do not want to PAY for it because they are hoping they will not need it, but those that have had a sensitive data exposure event occur are absolutely happier when they have been protected, than when they have NOT been protected.
There is absolutely a cost associated with adding Encryption to the database so that your data is protected At REST. But have those that are not doing encryption actually thought about what the COST would be if their data is accessed or exposed to the wrong party? If you think about reputation costs, recovery costs, revenue loss or customer satisfaction/loss, then I think that most ISVs would agree that the cost of implementing Data Encryption is a lot less than the potential loss of revenue associated with unintended data exposure.
So in this day and age where hackers are just a part of the way in which we live our lives using the Internet, why would anyone not just BUY the Insurance? Clearly there is a solution and a way to protect data in the cloud, so why would you not just implement it? Of course Encryption is only one piece of the puzzle, as there are other safety measures that need to be put in place. However, if Encryption is one of the foundational elements of protecting the data when it is At Rest – I guess I am just wondering why is it that everyone is not just taking advantage of it, if it is a proven form of Risk Mitigation.
As always any comments or thoughts, feel free to email me at firstname.lastname@example.org.
Colleen Smith is Vice President, Customer Advocacy at Progress. In this role, she is responsible for ensuring customer focus and accountability for improving the company’s relationship with its customers and partners, as it relates to the use of Progress core products. Smith joined the company in 2005 with 20 years of enterprise software marketing, sales and product strategy experience, and has helped transform software companies into industry leaders, built strategic partnerships, designed acquisition strategies and moved companies through aggressive growth stages.
Subscribe to get all the news, info and tutorials you need to build better business apps and sites
You have the right to request deletion of your Personal Information at any time.
You can also ask us not to pass your Personal Information to third parties here: Do Not Sell My Info
Copyright © 2020 Progress Software Corporation and/or its subsidiaries or affiliates.All Rights Reserved.
Progress, Telerik, Ipswitch, and certain product names used herein are trademarks or registered trademarks of Progress Software Corporation and/or one of its subsidiaries or affiliates in the U.S. and/or other countries. See Trademarks for appropriate markings.