What Asset-Based Risk Assessments Get Wrong
Wouldn’t it be nice to reduce risk management to a simple checklist? You could go down a list of business assets, answer a few questions, and be on your way.
That’s the thinking behind asset-based risk management, a buzzy risk management catchphrase. Unfortunately, this idea has more flash than substance and could lead a financial institution to overlook or underestimate risks, exposing the institution to unwanted risk, and creating the potential for noncompliance with regulatory expectations.
What Is an Asset-Based Risk Assessment?
An asset-based risk assessment examines risk by reviewing an institution’s assets. Asset-based risk assessments are most closely associated with IT, information security, and Gramm-Leach-Bliley Act (GLBA) and data privacy since on the surface these areas seem most closely tied to physical assets.
When it comes to IT security, the FFIEC Information Security Handbook defines assets as “hardware, software, information, and connections.” This may include major applications, general support systems, high-impact programs, physical plant, mission-critical systems, personnel, equipment, or a logically related group of systems.
An asset-based risk assessment begins with a list of assets. Each listed asset is individually reviewed to determine potential threats and vulnerabilities as well as the effectiveness of existing controls. The result is a long list of threats and controls by asset.
The Problem with Asset-Based Assessments
The problem with asset-based assessments isn’t what it includes – it’s what it leaves out.
Missing Element: Some Risk Areas Aren’t Addressed
The FFIEC IT Examination Handbook – Appendix A: Examination Procedures lists examination objectives that tell a financial institution everything that will be within an examiner’s scope during an IT exam, including in the area of risk management. Unfortunately, an asset-based risk assessment doesn’t touch many of these areas.
Asset-based risk assessments don’t consider things like:
- Policies and procedures
- Board management and oversight
- Board training and experience
- Risk management processes
Yet these are areas clearly within the scope of an IT exam as defined by the FFIEC’s listed objectives. For example:
Objective 2: Determine whether the board oversees and senior management appropriately establishes an effective governance structure that includes oversight of IT activities.
If your institution is relying on asset-based risk management, the governance structure will be overlooked, and the risks here will not be measured.
Objective 6: Evaluate management’s review and oversight of IT controls, including the other influencing functions of IT audit and compliance.
When looking at personnel and assets, compliance and risk management won’t be listed as an asset since neither is likely to be part of the IT department. It’s not enough to look at the individual controls protecting an asset. It’s important to understand the policies and procedures for reviewing and overseeing these controls.
Objective 7: Determine whether the institution’s risk management program facilitates effective risk identification and measurement and provides support for risk decisions within ITRM.
An asset-based risk management program isn’t going to evaluate the IT’s risk management program because it’s not included in the list of assets. It won’t address the risk of failing to demonstrate to examiners how management uses information from the risk assessment to make strategic decisions.
Any of these oversights could cause your institution to fall short of regulatory expectations if examiners decide to address these objectives in their risk-based exams.
When you assess risks by asset, you are looking at one small piece that is part of a much bigger enterprise. How are you going to tie it all together? The answer is that you won’t.
That means you may be unable to help examiners address these objectives:
Objective 3: As part of the ITRM structure, determine whether financial institution management has defined IT responsibilities and functions. Verify the existence of well-defined responsibilities and expectations between risk management and IT functional areas, such as information security, project management, business continuity, and information systems reporting.
IT doesn’t operate in a bubble. It supports functions throughout an institution. An asset-based risk assessment looks at individual assets instead of addressing the interconnected relationship between functional areas.
Objective 4: Determine the adequacy of the institution’s IT operations planning and investment. Assess the adequacy of the risk assessment and the overall alignment with the institution’s business strategy, including planning for IT resources and budgeting.
An asset-based risk assessment doesn’t consider the risk of failing to align IT planning and risk assessments with the institution’s overall strategic goals. Yet examiners may look for it.
Objective 10: Determine whether the institution maintains a risk identification process that is coordinated and consistent across the enterprise.
Objective 11: Determine whether institution management maintains a risk measurement process that is coordinated and consistent across the enterprise.
Objectives aren’t limited to just what goes on in IT. It also looks at the whole program. An asset-based risk assessment won’t provide evidence that the institution has a coordinated risk management program.
These are just a few examples of where asset-based assessments can fall short of regulatory expectations. An asset-based risk management program isn’t designed to connect the dots in a way that supports enterprise risk management (ERM). It examines the risks presented by single assets like laptops or a building. It doesn’t analyze risk by function, and it has no way to measure the expertise of the board.
But I Thought the Guidance Mentions Asset-Based Assessments?
Yes, the FFIEC guidance specifically mentions asset-based risk assessments. For example:
“Management should maintain inventories of assets (e.g., hardware, software, and information), event classes (e.g., natural disaster, cyber, and insider abuse or compromise), threats (e.g., theft, malware, and social engineering), and existing controls as an important part of effective risk identification.”
Note it says “part of effective risk identification.” It’s not the only tool needed. A list of assets is helpful in identifying those that store or transmit protected data and ensuring there are proper controls in place to mitigate cyber risk. But there is more to risk identification than assets.
Also, risk identification is just one step of the risk management lifecycle. Risks must also be analyzed, mitigated, and monitored. That analysis needs to tie into a system that evaluates risk holistically, providing insights that allow the board and management to make more intelligent decisions that support the institution’s strategic goals while fending off threats and maximizing opportunities.
Asset-based assessments just don’t do that.