To Store or Not to Store: That is the Question (and Other Best Practices)

I regularly attend a variety of security seminars and conferences. One common theme is that if you don’t have the data, you can’t lose the data. The idea is simple but profound. You see this reflected in a variety of best practice standards and regulations. For example, only collect the data you need for the specific purpose for which it is intended. If you need name and address to process a card transaction, then that is all you should collect. Do not also collect SSN and date of birth. And once you have processed that transaction, you should delete or destroy that sensitive data.

Keeping data, especially sensitive data, indefinitely is an invitation for trouble. This is one reason why inContact has a variety of tools that allow you to build an application that can consume data, use it and make decisions on it, without the need to store it within the inContact environment. We also have tools that can age and remove certain types of data.

Often, I am approached by the security personnel of prospective customers who are quite concerned about their data residing in our systems. I immediately explain that in many cases, inContact does not need to actually store their data. We have database connectors, web service capabilities and file transfer functions, which are all capable of using secure encrypted connections, that can be employed to allow them to build a solution that can consume the data without having copies of it stored within our network. This enhances security and allows them to retain control over the data – both items being of major concern to all companies considering or using a SaaS solution.

Now for the tricky part: in a SaaS environment, who is in charge of managing the data? Certainly, the SaaS provider is responsible for maintaining the systems and performs a myriad of management type functions… but when it comes to how long data should live, what data is stored and especially, who has access to that data, the SaaS customer is a primary responsible party.  

I worry sometimes that security is something that is thought about at the beginning but perhaps falls to the way side once things are up and running and because the SaaS systems are sort of "out of sight, out of mind," -- do they get included in the regular internal audits? Do password policies get applied and audited? Are data retention policies uniformly applied to SaaS systems the way they are to internally controlled systems? It is very important that a SaaS service be subject to the same scrutiny that is applied to internal applications and systems.

SaaS solutions are proving to be a great boon for businesses. Companies are adopting their use in greater numbers and their security people are engaging earlier in the process. A thoughtful implementation of a SaaS solution will minimize data kept in the cloud and will minimize how long data is kept on any system, keeping it only for the time necessary to conduct the transaction. Finally, SaaS customers will take the steps to ensure that their policies and procedures are extended to include data and access management in the SaaS environment. If you have questions, or would like assistance in how to utilize inContacts security tools, please contact your service delivery manager.