. . . they’re not required . . .
But they do have a place!
Another one of those Dan’s New Leaf Posts, meant to inspire thought about IT Governance . . . .
There is a myth out there that speed bumps are required for all weblinking relationships. This is simply not true. They are a useful control, but they are not always required.
First, let’s define “weblinking” as the act of putting a link on a website you control that links to a website you do not control. And let’s define a speed bump as an intermediate webpage which alerts the user to the transition to the third-party website. What it says is up to the bank, and varies from “we are not responsible for anything that happens from now on” to “the site you are heading to is not controlled by our bank.”
A speed bump is not a pop-up. While a speed bump is activated when the user clicks on a particular weblink, the use of a speed bump avoids the problems of pop-up technology. The speed bump is not generated using sometimes vulnerable code, is created solely on the institution’s system, and cannot be disabled by the user like pop-ups can (and should be).
Second, let’s be sure to understand that there’s been guidance on this subject since 2003. FDIC banks will want to reference FDIC-PR-34-2003, titled “Weblinking: Identifying risks and risk management techniques.” For institutions regulated by other organizations, there is an inter-agency guidance that the other agencies rely upon.
Pertinent to my point, the first three words of the guidance are A. Risk Discussion.
The guidance provides a lot of helpful information about the risk that weblinking exposes us to, and I found the twenty minutes it took to read the guidance was worth the time. The risks are not just reputational and legal, as I had expected. There are compliance and other risks as well.
Speed bumps should be applied as a control to mitigate risk. Like all controls, sometimes we need them, sometimes we don’t.
It makes no sense to use a speed bump when the destination site is the on-line banking provider. To control phishing risk and for marketing purposes, you want your customers to go there from your marketing site, and they go there more than they go to any other destination. It would create financial risk if you complicated the path to the site. Meanwhile, you have mitigating controls in place. Your on-line banking site is “branded” to your bank, and you perform annual due diligence upon the on-line banking provider, including reviews of third party assurance, financial condition, contract concerns, disaster recovery, etc. You insist your provider undergo regular testing, and you even participate in some of the tests.
And it makes a LOT of sense to put a speed bump between your site and an informational site where the information constantly needs to be updated, such as linking out to security awareness materials about how to protect yourself on-line. What infotex posted in 2000 is far different that what we post now. And you don’t control our site or even spend time making sure we keep it up-to-date. You wouldn’t want to be held liable if your customer experienced losses due to outdated information.
With these two extremes in mind, let’s consider the gray areas. If you have many weblinking relationships on your site, you probably have a gradation of values in the risk these relationships represent. Try to, using metrics, put these risk in context with other assets in your risk assessment.
If you don’t have the ability to risk assess the relationships, at least document your thinking when you do NOT use a speed bump. Most auditors would accept the two paragraphs above about on-line banking and information site weblinking relationships.
At a minimum, you should create a paper trail when deciding whether or not to speed bump the weblink to those “gray area destinations,” such as, for example, your mortgage application processor. Yes, you are vetting them, but they are also gathering a lot of information on your behalf, and some examiners think you should inform your customers that it is not you who immediately receives that information. On the other hand, I’ve heard loan professionals say “well then we might as well not offer the service, because the reason we’re doing this is so they can apply with OUR BANK, not Acme-Mortgage-App.Com.
Don’t get me wrong, I agree you (and your loan ops person) can make a case that the financial risk of customers NOT applying outweighs any legal or other risks associated with the mortgage application process, especially since you’ve fully vetted your on-line mortgage application provider. But since the case is not as clear-cut as the two extremes above, documentation of your thinking (and mitigating controls) is warranted. In other words, SHOW the discussion that the financial risk is greater than reputation risk + legal risk. (And show any mitigating controls you can put in place, such as the “branding” that you do with your on-line banking site.)
If all you have is a folder of e-mails about various weblinking relationships, that will sometimes be acceptable to an auditor. But the veracity of the discussion, and a clear summary of the decision with dates, needs to be in the folder. And could it be more helpful to your marketing department if you kept an inventory of the weblinks . . . . a list of relationships and associated risk, and whether the speed bump is there or not. And wouldn’t this inventory help ISOs and Internal auditors with their concerns . . . maybe even testing each weblink periodically to make sure they go to where you think they’re going?
So yes, you may have good news for your loan officers . . . . they don’t have to scare people away that want to apply on-line. But be sure to document the decision to share that good news, for each weblink off of your site. Do this not only so you can share the methodology and controls, but also to put your marketing team, not your auditors, in the driver’s seat!
Original article by Dan Hadaway CRISC CISA CISM. Founder and Managing Partner, infotex
Dans New Leaf is a fun blog to inspire thought in the area of IT Governance.
