Risk assessments are a required part of a financial institution's Information Security Program, but understanding how to perform one based on information assets is where many organizations get stuck. What counts as an information asset? How do you evaluate risk at the information asset level? And how does this connect to your Information Security Program?
If you've asked any of those questions, you're in good company. Asset-based risk assessments are one of the clearest ways to understand cybersecurity exposure, but only when the process makes sense. This guide walks you through an asset-based risk assessment approach.
An asset-based risk assessment begins with a simple question:
"What are we trying to protect?"
An information asset can be anything that stores, processes, transmits, or safeguards data. This includes the obvious items like servers, workstations, and critical software systems, but also the less visible pieces of your environment: cloud applications, third-party tools, and even the people who access your data.
The goal is to build a complete picture of the ecosystem your organization depends on. Without this, you can't accurately measure risk because you can't protect what you haven't identified.
Once the asset inventory is clear, the next step is to think about why each asset matters. Not all assets have equal weight. Each asset must be evaluated individually to determine its confidentiality, integrity, and availability (CIA) requirements.
To do this, consider questions such as:
This step turns a generic asset list into a prioritized one. Critical assets rise to the top, and less essential ones naturally fall to the bottom. This prioritization is what shapes the rest of the assessment process.
With your assets identified and prioritized, you can now examine the types of events that could compromise them. This is where cybersecurity risk becomes more concrete.
Here's a question to ask:
"What could realistically go wrong with this specific asset?"
For information assets, threats may include unauthorized access, data leakage, or cyber attacks. Technical assets may face threats from misconfiguration, malware, or physical damage. People are susceptible to social engineering and credential theft. Third parties introduce the possibility of vendor compromise and supply chain disruptions.
The key is to tie each threat directly to an asset. That's what makes it "asset-based" rather than a generic list of scary scenarios. For example, compromised credentials may always be a potential threat, but the risk is very different if those credentials grant access to the core banking system vs. the meeting room booking tool.
Now that the threats are defined, you can assess risk by evaluating the likelihood and potential damage of each threat.
Likelihood is your informed judgment about how probable an event is, based on your environment, controls, and threat landscape. Potential damage reflects the impact if the event occurred.
It's expected that organizations think realistically here. Not every threat is likely, and not every threat is catastrophic. The goal is to create a realistic view of your risks so leadership can make informed decisions.
With likelihood and potential damage in hand, you can then determine the risk of each threat.
Once risks are defined, the next question becomes:
"What are we doing about it?"
This is where controls come into the picture. Controls can fit into three categories.
The goal of applying controls is not to eliminate all risk (that's impossible), but to reduce risk to an acceptable level for your organization. For GLBA covered organizations, this is where your asset-based approach ties neatly into the requirement to "develop and implement administrative, technical, and physical safeguards to protect the security, confidentiality, and integrity of customer information."
Want to understand how this ties back to compliance? Read our What Is a GLBA Risk Assessment? blog, where we break down how information security and asset-based risk assessments support GLBA requirements.
After identifying risk and applying controls, the next step is determining how your organization will handle each risk moving forward. This decision-making process is known as your Risk Management Plan. Risk management typically falls into one of four categories.
| Risk Management Plan | Description |
| Risk Acceptance | The organization may determine that a particular risk falls within its risk appetite. In these cases, no additional controls will be applied, but the decision should be intentional, documented, and approved by leadership. Acceptance is not passive; it is a formal acknowledgement that the residual risk is tolerable. |
| Risk Mitigation | Mitigation is a common treatment method and involves adding or strengthening controls to continue reducing the likelihood or potential damage of a threat. This might include implementing MFA, improving network monitoring, updating policies, enhancing configurations, or adding staff training. The goal is to bring the risk down to a reasonable and appropriate level. |
| Risk Transfer | Risk transfer is a strategy where an organization shifts some of the impact of a risk to a third party, often through insurance, contracts, or outsourcing. While this can reduce exposure, the organization remains accountable and must continue to provide oversight. |
| Risk Avoidance | In some cases, the best course of action is to eliminate the activity that creates the risk. This may involve retiring a legacy system, disabling problematic features, or choosing not to adopt a high-risk tool or vendor. Avoidance is the most definitive form of risk treatment but often requires significant operational changes. |
Your risk management plan ensures every risk has a defined path forward that aligns with your organization's risk appetite, resources, and regulatory expectations. It also helps stakeholders understand why decisions were made and how those choices strengthened your overall cybersecurity posture.
A risk assessment is not a one-time event. It should be reviewed and updated regularly, at least annually, and whenever significant changes occur (new systems, major incidents, new vendors, process changes, etc.)
Good documentation includes:
This documentation becomes a defensible record that demonstrates due diligence, supports your Information Security Program, and aligns regulatory requirements to monitor and update your safeguards.
When you step back, the core of an asset-based risk assessment is actually very simple. It comes down to four key actions:
This approach gives you clarity, improves your ability to communicate risk, and strengthens your entire Information Security Program. Most importantly, it ensures you're focusing your time and resources on the assets that matter most.
If you want help performing this kind of assessment in a structured, repeatable way, the Tandem Risk Assessment product is designed to guide you through each step from identifying assets and evaluating threats to documenting controls, calculating residual risk, and generating clear reporting for your Board, auditors, and regulators. Learn more at Tandem.App/Information-Security-Risk-Assessment-Software.