Tom Hinkel, Account Manager
Risk management is a critical component of change management, disaster recovery, vendor management and technology management. Actually, if you think about it, virtually every decision a financial institution makes must either implicitly or explicitly ask, and answer, this “what if” question. For example, suppose we would like to consider relocating our IT systems to a hosted solution. The committee has identified several financial and strategic advantages to this strategy, and we would like to conduct a risk assessment to identify and address the “what if”s”.
First of all, why is this change being considered? Once that has been established, the first risk is what if the product/technology doesn’t perform as desired? Whatever strategic or competitive advantage you hoped to gain is lost, and there may even be additional financial risk if the project was a costly one. In the example above, did you hope to gain an advantage to your disaster recovery capability in order to address compliance issues? If the project fails to deliver, the compliance issues remain. Likewise if you hoped to gain certain strategic advantages.
Is the vendor a new vendor for the Bank? If so, have you updated your vendor management program by assessing both the criticality of the vendors’ service to your overall business strategy and the level of access the vendor will have to your customer data? Is the new vendor held to the same high security standard as you are, and have you assured yourself that their security controls are both sufficient and effective? A security incident by a trusted third party could have serious legal as well as reputation consequences.
Whether you decide to use a qualitative or quantitative approach (which really only affects step 2), risk management is a three step process:
- Identify the risk(s), categorized by
- Operational or transactional
- Legal or compliance
- Assess the impact, and rank by criticality
- Decide to accept or mitigate risk(s)
Let’s take our example above, and plug it into this three step process. First or all, what if our outsourced vendor suffers a security incident? We could be exposed to reputation, legal, compliance, and possibly financial risks, and the impact of each (or any) of these would be considerable. We remediate most of this risk by reviewing the third-party reviews and security assessments, and satisfying ourselves that their internal security controls are both sufficient and effective. The remainder of the risk should be addressed by the procedures defined in our incident response program.
If we are implementing this outsourced solution to address deficiencies in our disaster recovery program (itself a risk assessment), what are the operational or transactional risk implications if the outsourced systems don’t function as intended? These risks can be addressed by review of the vendor’ own disaster recovery program, and the results of their internal DR testing. The remaining risk is absorbed by your own DR program.
Hopefully this gives you a general idea of how the process should work. Because this process is so critical, every tech steering and compliance committee meeting should include a “what if” discussion on each agenda item. If you need further resources in this area, the Safe Systems Education Department is developing a Risk Assessment class that will debut early next year. In the meantime, your account manager can provide assistance with this process through their attendance at your committee meetings.