Subscribe / Unsubscribe Enewsletters | Login | Register

Pencil Banner

A checklist for SaaS vendors

Mathias Thurman | Feb. 3, 2016
Our manager’s company uses a lot of third-party vendors, and some of these relationships have been in place for years. What will happen when he goes back to assess their security risks?

It seems like only yesterday when most of a company’s corporate applications ran on servers within its own data centers. I remember, at previous jobs, having teams of application engineers and administrators building, managing and administrating all of the applications that allowed the company to operate — for email, HR, finance, sales, customer relationship management, learning management, marketing and more.

Trouble Ticket

At issue: Some third-party vendors were never vetted from a security perspective.

Action plan: Review them all, then minimize risks with compensating controls.

My current company has just two in-house applications, which run in a closet-size data center: source code management and a bug tracking system. Even those operations might be moved to a SaaS provider, as has been done for other things that now rely on more than 40 corporate-sanctioned and cloud-based applications. Many of the applications were put into service years before my arrival, and I’m just now getting around to evaluating the security risk of each of them. My top priority is the applications that process the most sensitive data for the company, such as Salesforce and ADP, which manage customer information, sales forecasting, personnel data and payroll.

I recently met with our IT department to discuss vendor management. We agreed that no new corporate applications will be allowed without first identifying risks by assessing the vendor and its service or application. To help with this, I created a spreadsheet for capturing answers to security-related questions. Such standardized information-gathering (SIG) questionnaires are nothing new, of course, so I was able to review SIG and other vendor questionnaires that I found on the Internet and pull out what I felt were the most important security questions and controls. I then applied weighted calculations to them.

For example, if the application processes sensitive data, I placed a higher weight on encryption than I would for an application that does something relatively innocuous like calculate tax or foreign currency conversions. For those tax and currency applications, I deemed items such as “restore point objectives” and “restore time objectives” to be less important and therefore in need of a lower weight than items such as applications that store business-critical data, such as those used by finance and sales, or even sites we use to store corporate documents, such as Google Docs and Box, where data backup and disaster recovery are critical risk factors. The resulting scores will be useful in choosing product and establishing compensating controls. For example, if an application that processes sensitive data isn’t compatible with our single sign-on solution but nonetheless offers the ability to control access in other ways, we might decide to use the application anyway, possibly doing something like restricting access by IP address as a compensating control.


1  2  Next Page 

Sign up for CIO Asia eNewsletters.