8 Questions Your Compliance Team Will Ask Before You Buy New Data Security Tech

Nathan Hunstad

Avoid these roadblocks at the end of your solution selection process

Data security and data compliance are very much related — but not the same. When it comes to choosing a data security product, it’s important that the solution meets not only your functional but also compliance and auditing, requirements. To help you zero in on the solution that will protect your data as well as help you avoid regulatory nightmares, it’s important to include these questions early on in vetting technology.

So, what are those questions about support, data storage, compliance, etc. that security pros should be asking of their vendors before moving full speed ahead on a new security tool? That’s where I can help. As Code42’s Audit and Compliance Manager, I enjoy partnering with IT and security teams to build an effective procurement plan that ensures we ask holistic questions throughout the procurement process. I’ve outlined the most essential questions to ask — beyond understanding the tech — before signing a new security contract. Here are my 8 suggestions:

1. Does this tool support my Identity and Access Management plan?

Does the tool have Single Sign On [SSO] integration, specifically with an SSO provider that includes Multi-Factor Authentication?
- Can (and how can) this integration be provisioned/deprovisioned?
Does the tool force SSO connectivity? Does it allow local accounts?
Does the tool have the functionality to create access roles, and does it have templates for secure roles and different access out of the box?
Can the tool query and export lists of users and their access or profile information in text/readable format?

2. Does the vendor have robust and accessible support?

Online videos, a learning library, a community of users, even some additional personnel resources? What are the options, and how many of them come with your licenses?

3. Has this vendor been approved via a vendor onboarding process?

Did the vendor pass your risk profiling investigation?
Has any security testing like: a pen test report, a static code scan report or access to source code analysis (if open-source) been completed?

4. Let’s look at how much this really costs.

How much time does it actually take to administer and maintain this tool, including, but not limited to:
- Access reviews; defining and maintaining access roles; internal audit evidence requests; on/offboarding users; licensing/contract renewal; vendor assessments; user management; new release management/features; communicating to end-users; application SME; reporting support; system administrator training and qualification and/or skills search (note: they’re a target for hackers); active directory management
- And remember, the higher the data classification associated with the data in this tool, the higher the risk to your ecosystem; meaning the more time it will take to maintain.
What’s the plan to realize benefits, whether that’s time savings, risk reduction or resource savings?

5. And of course, there are the obvious costs: licensing.

What is the licensing model? If they can’t explain their licensing model in easy-to-understand terms, that’s a bad sign.
Additionally, can the administrator separate duties, or have an admin-only role with separate license accounting from end-users?

6. Where and how is the data stored?

Is our data encrypted at rest/in transit?
What options are there for where data lives in cloud locations?
If the tool requires an endpoint agent or client, then, consider the following:
- Does the application work with Mac/JAMF, Microsoft/Intune, SCCM or your endpoint management tool?
- What is the client actually doing on the endpoint? Will something like probing that endpoint every time you need information require a ton of resources?
- Have you checked for any application conflicts or can the vendor provide them?

7. How do our data privacy goals and regulations affect the use of this tool?

Remember, there are two relationships to think about when it comes to data privacy: the company/customer relationship (subject of most data privacy laws) and the employer/employee relationship (here's an example of an Acceptable Use Policy).

8. Speaking of regulations, you should definitely consider a few more (depending on your business):

Is the vendor/application ISO, SOC2, SOX, GDPR, HIPAA or FedRAMP compliant? Learn more about Code42’s regulatory compliance and how our data protection solution works for GRC teams.
Would this application be compliant with our regulatory needs? Could it help our organization with our own regulatory compliance efforts?

We’ve all hit that roadblock in the final stages of buying a technology that the organization really needs. To prevent those momentum killers, make sure you’re keeping an eye out for ease of deployment, compliance and data auditing as you make your way through the process of researching and buying security technology.