Third Party (vendor) cybersecurity risks are critical for small businesses to understand and mitigate. Fortunately, third party risk assessments are a cottage industry for laws firms and compliance companies. Unfortunately for small businesses, while these outsourced assessments are comprehensive they are often unaffordable for small companies. Even the smallest companies typically have several dozen third parties requiring risk assessments.
I am proposing a tailored process for small businesses that can be done by mid-level security engineers who also have general IT and business knowledge. There are 3 key steps in preparing the third-party risk assessment:
1. Understand the corporate use cases for the vendor under consideration.
2. Request vendor documentation.
3. Follow-up vendor questions to clarify any uncertainty around the corporate use cases.
These three steps will become “evidence” used to support your risk report and should be stored securely as a risk assessment package along with the risk assessment report. The third-party risk assessment package is good for compliance audits and revisiting how the risk decisions were made if the use cases change in the future.
Steps #1, #2, #3 will probably average somewhere between one to two(ish) hours to complete, and the risk assessment report should take about 20 to 30 minutes to complete.
Understand the corporate use cases: As a security professional, it’s important to highlight risks and design mitigations that are specific for the business that you are protecting. This means that you need to have at least a high-level understanding of how a third party will interact with your corporate data, users, and infrastructure. It also means that your security engineer makes a professional judgement about the effectiveness of the third party’s security program to determine risks. As an example, consider the simple case of a potential outsourced background check provider that you have been asked to conduct a third-party risk assessment on as part of the diligence process by a small company.
Step #1 — Corporate Use Cases: Identify the internal business owner of this background check process and present some use case questions to ask them, like:
1. What is the scope of the service — who will be interacting with it?
2. Who submits the data to the outsourced provider?
3. What sort of data is required for each person undergoing a background check?
4. How do you communicate with the provider that a specific person needs a background check?
5. How is the background report provided and what data is on it?
For a background check — it’s probably a safe assumption that there will be Personally Identifiable Information (PII) provided by anyone undergoing the background check. This is the highest category of data to be protected by most small companies. I am also going to assume that the use case answers come back like this: Employees on hire are required to fill in a web form provided by the background check company and enter their PII on the website. Somone in Human Resources picks up the final report after XX number of days via an administrative web portal, and the report has no PII in it. The background report is downloaded for review and filing.
Step #2 — Request Vendor Documentation: Ask the background check vendor for any SOC II reports, security program documentation or standardized security questionnaires (e.g. — SIG, SIG Lite) that they may have responded to in the past. I do NOT recommend providing some sort of questionnaire to the vendor — since the market has been flooded with variations on questionnaires that cover security programs in varying levels of depth.
The documentation that you receive is useful for the content but also the quality is indicative of the focus that the third party has on security. Basically — there are “meta messages” outside of the content to pay attention to. A SOC II is better than a questionnaire because it includes third party auditing / validation of controls being implemented. A standardized questionnaire is better than a home-grown questionnaire (Excel or otherwise) because they are generally comprehensive and involve compliance participation (e.g. — versions of the full SIG expand to over 700 questions based on how certain top-level questions are answered!). A company unique questionnaire or due diligence form is less comprehensive and often harder to draw security risk conclusions from at times, but it’s better than employee information security manuals. You get the idea — assess the meta messages concurrently with the actual content to inform your risk assessment.
Step #3 — Follow-up vendor questions: I am considering writing an additional in-depth article on the items to look for during a security documentation review. However, the simple approach is to use professional judgement and focus on four key areas:
– Is the program comprehensive and does it make sense holistically “as a program” in protecting your corporate data / intellectual property / trade secrets?
– What are the key missing areas?
– Gauge the level of security focus that you assess the firm at.
– For your corporate use cases — what matters? What level of data classification will the third party be handling?
Make note of any questions as you read the documentation — sometimes they are answered later in the documentation. Continuing the background vendor example — the highest-level data being processed is PII, ingestion is via a website hosted by the background check company and final reports are delivered via a portal hosted by the background check company. Given the use case outlined above — for a background check vendor, focus on specific areas of risk.
For the four key areas above — what’s missing in protecting PII that the background check vendor is handling? What would make you more comfortable about how seriously the third party takes security — does it really matter that the CEO or Board never review cybersecurity risks? It’s better to go back with a series of questions and receive clarification than make faulty assumptions. For example — the background check company mentions holding penetration tests (pentest) in their documentation. A good question might be “When was the last time that you held a pentest and what were the results?” Essentially the types of questions are based on your judgement in trying to understand the risks to corporate data (including PII for our background check service provide example).
The Third-Party Risk Assessment Report: Unlike the more formal cottage industry assessments — you just need to arrive at a handful of specific risks, and recommendations. Lightweight and focused on the essential risks and recommendations are the key operating principles — the report in most cases will take not more than a half(ish) page of text when done well (with your evidence as attachments). The template elements:
– Summary of the vendor, usage and risks.
– Control recommendations to mitigate/lower risks and likelihood.
– Business Decision to be made.
– Evidence list and attachments.
A sample write-up for our fictitious background check vendor:
START OF SAMPLE REPORT
[MYCOMPANY NAME] Third Party Risk Summary for [VENDOR NAME]
[VENDOR NAME] is a background check service provider. Based on [COMPANY NAME] use cases, my initial risk assessment for using this vendor is High Impact and Medium Likelihood. My confidence in the risk impact is very high and confidence in the likelihood is medium. The Risk is High because the proposed use cases include Personally Identifiable Information (PII). The Likelihood is medium because (1) [VENDOR NAME] was recently acquired by a larger company and has not fully integrated into the more mature security processes of the new company, as evidenced by discrepancies in the SOC II documentation provided and the follow-up questions; (2) Good oversight and regular review of cybersecurity risks by the CEO; and (3) Vulnerability scanning conducted monthly. The residual risk to [VENDOR NAME] is High impact and Low likelihood based on [VENDOR NAME] controls for (1) Implementation of continuous monitoring and (2) encrypted database fields for data at rest.
[MYCOMPANY NAME] Control Recommendations
To reduce the Impact risk to Low and increase my confidence in the Low Likelihood, I recommend the following controls:
1. [VENDOR NAME] supports “Bring your own key” functionality — implement a custom key that is managed by [COMPANY NAME] in the event that data is stolen from the third party.
2. Business owner sign-off for any business confidential or PII data stored by [VENDOR NAME].
3. Include a contractual clause in the [VENDOR NAME] contract where [COMPANY NAME] agrees to provide access control logs quarterly for any access to [COMPANY NAME] PII. Implement an internal review process quarterly.
4. Modify existing [COMPANY NAME] data loss prevention controls to prevent/monitor PII.
5. Include contract language that at the termination of the contract all [COMPANY NAME] PII will be removed from onsite and offsite backups.
Business Decision to Make: The initial Risk is High and Likelihood is Medium, so a business risk acceptance/mitigation decision is required. Acceptance of the risk and requiring the recommended controls to be implemented is a business decision to be made by the business process owner or in accordance with [COMPANY NAME] risk policies.
Evidence — Please store the attached files along with this report in a protected folder only accessible by authorized users. Third Party Risk Assessments should be considered highly sensitive because they provide insights into weaknesses and compensating controls.
1. [COMPANHY NAME] uses cases attached as a PDF file
2. SOC II provided by [VENDOR NAME]
3. Follow-up questions email chain stored as a PDF file
END OF SAMPLE REPORT
There are a couple of key things to note about this write-up. It focuses on initial risk and residual risk based on security engineering professional judgement of the third-party documentation and questions. Make sure that you provide some rationale for your judgements so that they are something more than “because I said so”. The evidence is important for future audits — but also to detail the use cases that were disclosed and envisioned. My experience is that these use cases change over time and without documentation it can be hard to justify changes in security mitigations.
Most importantly — a BUSINESS OWNER makes risk decisions for anything above low risk, not IT or the cybersecurity team. A final note is that well intentioned engineers and businesspeople will argue about the friction imposed by security controls. The process and format here try to provide transparency about the key risks and recommendations as a basis for those future conversations.
The benefits of keeping third party risk management in house for small companies goes beyond saving cost. It keeps security practitioners close to business uses cases, increases communication and collaboration with internal business partners, and should have the overall effect of increasing the relevancy of security work done on behalf of keeping small companies safe.
If you are a small business executive — would this third-party risk assessment be useful? If you are a cybersecurity professional — what would you tweak?
David Mosher is a CEO, Board Member, virtual Chief Information Security Officer (vCISO), MS in Cybersecurity, PhD Student in Cybersecurity Mgmt.