Another Manifesto

A supply-chain manifesto by the author of Never Say Never: A Password Manifesto!
Another one of those Dan’s New Leaf Posts, meant to inspire thought about IT Governance . . . .

[Sssshh.  Turn out the lights.  Let’s lower our inner voices, as I have something to propose that might be a bit ahead of its time, like my article about password aging a decade ago.]

In 2013, I helped a bank being hammered by an exam finding that required them to rewrite their entire vendor management program.  A member of the committee that helped with the engagement was a lawyer who, being on the board of directors of a bank, was very concerned about the extra compliance work that was arising from the notion of “Information Technology.”

In grilling me about my business, he learned that I oversaw a company that was in the FFIEC’s technology service provider examination program, and that I was being examined (literally that week) on a two year cycle.  He was fascinated by this . . . that the federal government would be in my office examining us as if we were a bank.  Almost as if I was in a deposition, I answered his questions, as he continued to drill down as far as he could, given that I was not allowed to share what happened in my exams.

This lawyer actually followed the link I had provided in my training to the guidance on the TSP Examination Program, downloaded the PDF of that guidance, and came to the conclusion that . . . “given my connections in the industry” . . . we should try to lobby the FFIEC to exempt community-based banks from having to review vendors that were in the TSP exam program.  As far as he could tell, the federal government was doing everything that they were requiring community-based banks to do.

At the time, I’ll have to admit, I told him I would look into it, flattered that he thought I was “connected.”  But I never was able to find a good time to raise it with governmental people I know.  The idea died right there, in 2013, and didn’t resurface again until we wrote the “interim post-mortem review” on the SolarWinds Incident  (I still love how something can be “interim” and “post” at the same time!).

But when our post-mortem review process drilled into the management lessons and action items, we realized that one of the things bank management could do was lobby the FFIEC to streamline the vendor management process so that community-based banks would not have to spend time on any residual risk that wasn’t high or critical.

Assuming inherent risk is high in order to get into the FFIEC TSP Exam Program, we are proposing community banks be exempted from the Assurance and Insurance aspects of due diligence with vendors in the program.  Banks would still need to perform contract, financial, and business continuity aspects of this review.  And we would still want community banks to review the TSP ROE, the SOC User Entity Control Considerations, and the “inventory of subservience providers” that arises from a SOC 2 review.

I understand and agree with some of the pushback that examiners would give on this notion.  They will tell you that the agreement and relationship between bank and vendor is already very customized and that the FFIEC exam is for generic inherent risk and not custom residual risk.  As a risk manager, I understand that notion, but I submit to you that there are many vendors NOT in the FFIEC examination program and the assurance review for these vendors suffers due to duplication of efforts with TSP ROE holders.

And I submit that sometimes we need to say sometimes.  Sometimes duplication of effort only hurts the overall process.  That is one of the takeaways of the SolarWinds incident.

The parts of the relationship that are custom is the contract, the user entity control considerations and the business continuity arrangements.  We do produce one set of financial statements for one Client, and another for a different Client.  So why should our Clients review them with the FFIEC already does?

If as bankers we could focus on the parts of the relationship that is INDEED custom to the bank, we would understand the business continuity arrangements better.  We could incorporate their tests into our own better. We can follow the residual risk, not the inherent risk.

Sometimes, we need to say sometimes.  I agree that in some cases, we should review everything.  If an FFIEC TSP Exam report does indicate there are issues, we should follow that.

Of course community banks will need to continue reviewing their vendor contracts.  That’s where the customization is defined.

Therefore, and this is where I’m a bit shy . . . . I encourage each person who reads this article to share it with the person in your bank who is responsible for lobbying your congressman.

We can really make a difference in community banking on this one, it is very clear to me that the TSP examination program already covers assurance from enough angles.  The FFIEC should learn to say sometimes, sometimes.  If the vendor is not in the TSP examination program . . . definitely look at the assurance.  But if the vendor is in the TSP examination program, maybe community-based banks under a billion should be exempted.

[Okay, we can turn the lights back on.]

Original article by Dan Hadaway CRISC CISA CISM. Founder and Managing Partner, infotex

“Dan’s New Leaf” is a “fun blog to inspire thought in the area of IT Governance.”