Assessing Security Risk in IT Vendor Relationships
Third-party IT vendors are embedded in modern technology stacks; from SaaS and AI platforms to Managed Service Providers (MSPs) to one-off integration tools, vendors often are required to maintain an efficient business workflow. With that requirement comes access to sensitive systems, data, and information, which continues to expand the ever-growing number of attack vectors that cybersecurity professionals need to monitor.
Many recent high-profile organization breaches did not originate internally but through a vendor. That reality has brought vendor management and their security to the forefront of IT leadership.
This article will cover practical approaches to vetting IT and IT adjacent vendors at a high-level discussion with a focus on:
- Backend architecture and infrastructure
- SOC 2 reports
- Day-to-day security practices
As is often the case with IT Security, there is always a balance between locking down every possible avenue of attack, juxtaposed with allowing users to be able to actually perform their typical daily work functions. The goal here is risk awareness and informed decision making.
Architecture and Infrastructure
Security starts with infrastructure and the backend technology supporting whatever tool or application one is utilizing. It is always worth asking a vendor what their system actually runs on. Ask the vendor if they run on a public cloud, and if so, what is that cloud (AWS, Azure, Google, etc.)? If they are self-hosted, ask if they own their own data center or if they are in a co-located data center. Do they manage their own environment or depend on their own third parties for monitoring and administration?
Public cloud usage is not inherently more or less secure, but it shifts the responsibilities involved. In a cloud environment, providers secure the underlying infrastructure, while vendors are typically responsible for OS configuration, patching, identity, and application security.
In a co-located environment, the post shifts a bit more towards the vendor, as they manage the underlying hardware, but often the co-location owner is responsible for some of the perimeter security, as well as physical security and power and cooling redundancy.
Mature vendors should be able to articulate their own, as well as their own vendor’s, responsibilities. A red flag isn’t where their computer is located, but a lack of explanation of who is responsible for what.
Evaluating SOC 2 Reports Beyond Simply Asking If They Have One
SOC 2 reports are often treated as a Boolean answer: You have one, true or false?
A modern approach to vendor management sees this as a mistake. The first step is to understand the different types of SOC 2 reports, meaning Type I vs. Type II. Type I is a snapshot of controls at a point-in-time, while Type II is a validation of those control’s functionality over a set period of time. From a risk perspective, SOC 2 Type II is significantly more meaningful, as it demonstrates not just intent, but consistency.
Additionally, all SOC 2 reports evaluate IT Security, but some also include availability, confidentiality, processing integrity, and privacy. An organization should ensure the criteria align with how they use the service. For example, a vendor handling sensitive customer data should cover confidentiality, not just security.
Other important sections of a SOC 2 are often skipped in the vendor evaluation process, including control exceptions, auditor notes, and management responses. One or two minor findings are normal. Repeated exceptions, vague remediation plans, or controls that “will be implemented” in the future deserve reevaluation.
Day-to-Day Security Practices
This is a section pertaining to one of my favorite recent terms, “Cybersecurity Hygiene.” Policies are important but following them as a part of a daily routine matters much more, and security must start at the top. Some key indicators of mature security hygiene are multi-factor authentication (MFA) for all employees and admins, role-based access control, regular access reviews, and conditional access policies.
Ask the vendor how they identify any vulnerabilities, prioritize critical patches, and verify remediations were successful. Ask how they monitor their systems. Do they use centralized logging, a SIEM (Security Information and Event Management), and/or alerting for suspicious activity and potential intrusions? The answers don’t have to be a firm yes for all of these, but a clear understanding of both the yes and no indicates an understanding of what these systems are used for and why they are needed.
Another thing to ask about is the human factor. Are employees trained and tested on security awareness, and if so, how regularly? Are background checks performed for sensitive roles? Is there a dedicated Security Officer and/or team? A vendor that says, “security is everyone’s job,” but no one owns the process is a clear risk.
Final Thoughts
It is important to realize that these questions do not have clear cut yes or no answers but require a mutual understanding of the security practices and functions of a vendor organization as a whole. Some clearcut red flags are:
- An unwillingness to share security practices or documentation
- Having an outdated SOC 2 report
- Showing little to no concern for security
- Having no clear breach notification process
When evaluating the third-party organizations, it is important to remember that you are trusting these vendors with not only your company’s data and information, but also your reputation. Trustworthy vendors are transparent and knowledgeable.
For more information on Cybersecurity risks, response and more, be sure to visit our SOC & Technology Consulting, Cybersecurity, and Forensic Examination pages, and don’t hesitate to contact Dave Hammarberg regarding our services.
About the Author
Dustin Kinn joined McKonly & Asbury in 2022 and is currently the firm’s Director of Information Technology.
