I know compliance requirements can feel like a burden…and doing compliance solely for the sake of compliance can really feel like a burden. Taking a step back from the checklists and trying to see the spirit of the law can help to keep you from being overwhelmed. It can also help you clean up the parts of your information security program that may have gotten out of hand over the years. Vendor management is one area that can get overwhelming and unnecessarily complex when you try to check things off without truly understanding the process. Vendor management also seems to be on many examiners' radars this year, so now is a great time to clean up your vendor management program and make it work for you instead of the other way around.
One area where I see the most confusion is in the collection of vendor due diligence and oversight documents. These are things like financials, SSAE16 reports, confidentiality agreements, etc. Too often I see that the oversight requirements for vendors are just based on the documents the vendor chooses to give the bank. This works great for core vendors who already know what they should give you and automatically provide it. It doesn't work so well when you work with other vendors who aren't as familiar with GLBA requirements. It's your responsibility to know what you want from each vendor. The best way to do this is to think about what each document is and what it would tell you about a vendor…if the information would help you manage the risk associated with that relationship, then ask the vendor for that document. If the information isn't necessary, then you don't need it. Here are a few of the more common vendor documents and what they tell you:
- SSAE16 or other audit reports: test the controls the vendor has in place, much like what happens when your bank has an IT audit. This is needed for vendors who store any unencrypted customer information or if the vendor can access your network without your permission. Make sure you check out the scope of the audit to ensure it was thorough.
- Financials: show you the vendor's financial health. You'll want these from companies you couldn't easily replace if they were to go out of business.
- Confidentiality Agreement: If the vendor has access to or stores customer information, you want to know that they will use the same strict standards of confidentiality that your bank uses. If a security breach on the vendor's network could potentially lead to a breach of your customer's information, then you also want some kind of incident notification language (the vendor agrees to notify you if something happens).
- External Security Testing: Just like the penetration test that you do annually, this will test how visible and vulnerable a vendor's network is from the outside (Internet). You want this for any vendor who is hosting sensitive or critical information, including your website. If a vendor has had a SSAE16 performed, external vulnerability testing might be covered, but you need to check the scope of the SSAE16 to verify.
- BCP documentation/testing: there are two types of BCP testing that you may or may not need from a vendor. One is from the vendor's location to its backup site. This is the same kind of testing you would do if you were failing over to your backup location, and it lets you know how prepared your vendor is and how much downtime you would have if a disaster affected your vendor's location. The other type of test is a backup connection between you and the vendor. If something happens to your connection to the vendor, how quickly can the alternate operating procedures be up and running? The types of testing, if any, you want to see from a vendor just depend on the nature of the relationship and how important the availability of this vendor is to your bank's operations.
Vendor relationships are not created equal, so a little organization and understanding from the beginning can save you time each year as you save and review these due diligence documents.