As you work through the rigorous SOC 2 requirements, it is easy to get tunnel vision because so much of your work focuses on protecting your customers and their information. But what about the vendors you work with? Do you have a third-party IT vendor management policy to address the risks they bring to your organization?
Unfortunately, vendors are a huge entry point for hackers that is often overlooked in risk management. Most companies don’t even know the number of vendors that have access to their data and what the vendor’s employees are doing in their network. The purpose of the IT Vendor Management Policy is to identify which vendors put your business at risk and then define controls to minimize those risks. This includes so much more than service levels, management processes, and contract management. It goes back to your core business requirements and why they have access at all to the data in each of your business units.
4 practices to consider when creating your IT vendor management policy
Evaluate vendors
IT services vendors are generally very good at assuring you their product or service is like oxygen - you can’t live without it! They will throw around a lot of acronyms and buzzwords like “next-gen” in hopes of dazzling you into signing on the dotted line. Resist that temptation for now, and instead create a template with questions to help you do the proper amount of due diligence and select the right vendors. Sample questions include:
- What happens if your system stops working? How does this impact your product or service?
- Have you completed a SOC 2 certification?
- Do you complete an annual pentest?
- What does your SLA look like?
- How will your service help your organization achieve its business goals?
After completing the questionnaire, read through it and ask yourself, “Does the vendor clearly understand their responsibilities? And do we, as the company, fully understand ours?” If you can’t confidently answer “yes” to both questions, you may need to ask more questions. When all the data is gathered, put all the answers side by side so you can make a well-informed decision on which IT services vendor to choose.
For the long term, even if you’re happy with vendor performance, make sure you evaluate new vendors again by putting out RFPs at the end of each contract life cycle. It’s always a good idea to see what other offerings are out there, and if nothing else, it keeps your existing vendors driven to give you the best cost savings and service.
Plan for failovers
Even with SLAs and uptime guarantees in place, it’s likely that you will face a vendor service failure at some point. You can minimize the impact of a failure by having another vendor in place as a failover. This failover plan should include:
- Know what is affected by a vendor service failure
Don’t wait until an actual outage with one of your service providers to learn what other services are affected. Create a diagram of your vendors, the services they offer, and where any interdependencies exist between them. Ensure this diagram also lists the support phone number and key contact person for each vendor so you can get ahold of them immediately for updates.
- Establish redundancies whenever possible
For example, if your ticket system fails, you will probably need to rely on other channels such as email and chat because of the high cost and effort required to maintain two different ticketing systems. Other systems, such as Web applications and databases, might offer an automatic failover configuration if the primary fails.
- Create an internal response plan for each vendor in the event of a failure
Practice the response plan every six months with a tabletop exercise. You can start with something basic by having the teams gather in a conference room and talk through a feasible failure. For instance, ask the group, “What if we lose this primary system?” Flesh out all the steps, and be sure to play devil’s advocate in the discussion as much as you can. This will help strengthen your response plan to cover as many “what if” situations as possible.
- Write a templated response to communicate failures to customers
In the stress of the failure itself, it’s easy to get into an all-hands-on-deck situation and have everyone focus on nothing but restoring service. However, just as important as restoring service is keeping your customers abreast of the situation. Common channels to communicate service status is through a dedicated Twitter account or a “status.yourdomain.com” Web page.
Know who should be involved
Many young and/or small companies don’t have a dedicated vendor manager on staff, so you may need to assign that responsibility to a third party. Regardless of who holds the vendor management role, make sure your management (usually the CIO or CISO) is involved in reviewing and selecting vendors. They should have a say in evaluating necessary business justifications and help you approve or disapprove vendors accordingly.
Hold vendors to the same standards
Just because your service providers meet your compliance criteria, it does not mean they will provide you with a secure environment. If you have specific security expectations, include them in the vendor contract details upfront. You cannot simply assume they will take responsibility for the level of security you require.
Before finalizing any contract terms, conduct a careful review of the vendor’s contract, SOC 2 certification (if applicable), and security controls to ensure the vendor meets your security posture. The main takeaway in these service-level agreements is that each party should have a crystal clear understanding of what their responsibilities are.
As part of an effective risk management strategy, you need to establish good vendor management practices. Ask plenty of questions early in the relationship, create failover plans and ensure that your CIO or other senior leadership plays a part in selecting the vendor selection process. Don’t sign an agreement until you’re completely confident that everyone understands their role in the vendor relationships and will meet or exceed your security requirements.
To learn more about how StrongDM helps companies with vendor access, make sure to check out our Vendor Access Use Case.
