Due Diligence and Ongoing Monitoring

When evaluating third parties that provide multiple services, is it typical to send out one external due diligence questionnaire or one for each service? We use more of an all-encompassing questionnaire. The majority of questions within the questionnaire are more "third party" than "service" focused, so sending multiple questionnaires would seem to be redundant. We perform due diligence on each service, but with the responses with one questionnaire and the supporting documents supplied by the third part. I am interested to see how other financial institutions perform due diligence under these circumstances.

I also would like to know the best practice.  We are a small CU and deal with companies that MANY credit unions utilize.  

We are a small credit union so not nearly as many vendors as some others use. There are some vendors that are consistently delayed in getting me their due diligence docs in full to review. I have departments chunked into months for their annual reviews starting with June and ending in November. If for example Marketing is due in June and all but 1 vendor has provided their docs, I complete the departmental review and report to the board they have been completed with the exception of X vendor due to (insert reason) When I complete the review for X vendor, I note that in the board packet whatever month it is. Now if for example Marketing has multiple vendors unable to meet our deadline, then I look into why and when I expect to get them. I then permanently move the whole department to a different month where I know I can complete their review all at once.  

We have been using one questionnaire and ask that the vendor indicates on the questionnaire if the answer does not apply to a product. We also ask them provide documents that cover all products. Alternatively, major and well-established vendors may provide a CAIQ or similar document for each product. We have also made a matrix in a spreadsheet to chart the documents obtained for each product.  If the document is not applicable, we chart it as N/A. 

If the vendor is low risk, we require just a handful of documents from the vendor. As their risk level increases, the number and types of documents we want to see also increases.

We start our vendor risk rating process based on the level of risk for the service/s we are contracting for.  Many vendors offer different services, and those services could be low risk to high risk. So, once we determine the level of risk for the service/s, we request documents based on the riskiest service we are contracting for with them.  Whether we are getting one or multiple services from the vendor, and the risk for all is low, we request the limited number of documents.  If we are getting low and high-risk services, we request documents based on the vendor being high-risk. If we currently have a low-risk service from the vendor but add a high-risk service from them at a later date, we ask the vendor for the due diligence documents for a high-risk vendor, and they now become a high-risk vendor for us.

This message was posted by a user wishing to remain anonymous

Starting with Microsoft, Oracle, IBM, Salesforce, and other companies, each product gets its own risk (with emphasis on NPI and ePHI data involvement as well as cybersecurity maturity equal or better than ours). Same for SaaS vendors for which each subscription (i.e., Atlassian JIRA is seen different than Atlassian Bitbucket Cloud, Tableau vs Salesforce, etc.) is seen as completely different.

However for the questionnaire - we found sending the questionnaire after the basic due diligence (SOC 2 Type II reviewed, customer interviews, etc.) is completed helps reduce the overhead for the vendor on subsequent products or subscriptions.   While the vendor security liaison must complete (yes / no) each question and sign off, we do note in comments whether we are aware of evidence within SOC 2 or other material that addressed our concern (i.e., CC2.1 on Page 54 in Section IV of their SOC 2 for particular vendor where same SOC 2 addresses more than one service).