Vendor selection: What needs to be in a good policy
Operating a company in the modern enterprise landscape requires a reliance, to some degree, on third-party vendors. It's unavoidable. But the addition of each new vendor brings with it a certain amount of risk.
In the past few years, vendors have been at the center of high-profile breaches at major firms like Target and Verizon. However, companies don't have to accept data breaches as the status quo for working with outside partners, and can take steps to mitigate the risk of bringing on a third-party provider. It all starts with a proper policy that accounts for vendor security audits.
Starting small is key. Company leaders should work with their CISO or CSO to determine their minimum acceptable security standards, and use that as a baseline criteria, according to Gartner research director Mark Horvath. This should be done even before a request for proposal (RFP) or request for information (RFI) is written, Horvath said.
"Every organization will have a set of requirements which are informed by the relevant industry standards and the unique needs of the organization. These should be written as a policy long before any vendor inquiries are made, so that they can be addressed up front with the vendors. The goal is to avoid the problem of buying a product and then discovering later that it violates privacy or security policies in a way which hinders the business case for the purchase."
SEE: Ethics policy: Vendor relationships (Tech Pro Research)
Once those minimum requirements are determined, the company must look at each vendor individually. There will not be a standard approach that will work with each type of vendor, according to Daniel Kennedy, research director at 451 Research.
A good place to start with separating the needs of different kinds of vendors is by creating a risk quotient around each vendor's product or service. This will help a company better decide how much time to spend on an assessment.
Kennedy recommended asking the following questions: "Is the vendor handling or managing some type of critical data, whether intellectual property or customer personal information? Is the vendor product/service involved with a critical business function, or directly affect revenue or expenses? Is the vendor's service a single point of failure?"
Once these questions have been answered, a company can begin its due diligence, Kennedy said. Companies should send questionnaires, interview key employees at the vendor, request materials, and try to schedule a site visit if possible. According to Kennedy, these are some additional questions a company should be asking the vendor:
- Is the vendor mostly free of negative publicity?
- Can the vendor provide references to confirm that it delivers on contractual obligations?
- Does the vendor have a security officer and clear security policies in place?
- Does the vendor have a realistic business continuity or disaster recovery plan?
- Is the vendor financially viable? (i.e. Are they profitable, or are they still running on investor funds? Do they have other large clients? What is their exit strategy?) Can they turn over a SSAE 18, SOC 2 report if appropriate?
- Does the vendor perform third-party vulnerability assessments of their services, and will they share the results?
- Will the vendor agree to additional testing?
- What provisions can the vendor support for ongoing assessment of their controls once the contract is signed?
Horvath also recommended that companies ask the vendor to provide a manifest of the open-source code they use in their product or service.
"Open-source code is widely used in application development, which is fine, but OSS libraries are often updated in response to security evens (e.g. Heartbleed), so knowing what open-source code is in a product is critical to being able to maintain it," Horvath said.
Of course, there are also the standard contract elements that must be considered, Kennedy said. Enterprises should work with their IT leaders and executive team to draw up SLAs for availability, quality, and responsibility. Other factors to consider include insurance needs, non-disclosure agreements (NDAs), and what will happen in the event of a data breach.
Unfortunately, Kennedy said, many companies think they are covered under state laws, but those often don't protect an impacted firm from having to notify its own end users.
"Those customers don't blame the tiny supplier they didn't even know about, they blame you," Kennedy said. "Under what terms can you get out of the contract, or reduce its scope if conditions change?"
Prior to purchasing, a company should be able to validate the vendor's testing processes, including their methods for testing application security, Horvath said. Knowing how the vendor will notify their customers in the event of an outage is also helpful, as it allows the purchasing company to more effectively alert their own users, and to remain compliant with regulations like the EU's General Data Protection Regulation (GDPR), said Horvath.
Speaking of compliance, Horvath also noted that vendors should be required to provide a policy for protected data, and proof of compliance with appropriate standards for the company's industry. Understanding a vendor's data retention, attribution, privacy, and deletion processes, and whether or not company data will be deployed to the cloud, is also critical.
In considering the vendor security audit as a whole, Forrester Research principal analyst Duncan Jones recommended integrating that audit with other assessments such as service reliability and financial stability.
"Too often I see discrete assessments by different functions, which overloads suppliers and creates gaps through which risks can enter the organization," Jones said. "You need one single platform to manage and record all the assessments, including security."
Adapting the audit to the context of the vendor and what product or service is on the table is also important, Jones said. However, don't write off startups and smaller companies, he added. Rather, "refine the process so that you can work with emerging suppliers on innovation and pilot projects without completing a full audit, because being overly risk averse stifles innovation," Jones said. "Try to defer the assessment until you are ready to scale up the relationship."
Finally, consider the data. Companies should look to providers that collect risk data about certain vendors, and "syndicate that out to multiple clients -- a sort of community-based approach, rather than an egocentric one just for yourself," Jones said. "That reduces the workload for the suppliers and for you, and improves the reliability of the intelligence collected."
Also see
- Special report: Cybersecurity in an IoT and mobile world (free PDF) (TechRepublic)
- How to manage vendors in a cloud-first world (ZDNet)
- Scrum agile project management: A cheat sheet (TechRepublic)
- How to choose the best tech vendors: 3 tips (ZDNet)
- How to avoid vendor nightmares (TechRepublic)