How to Perform an Information Asset-Based Risk Assessment

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.

Identify Your Information Assets

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. 

Determine Each Asset's Importance

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: 

• Confidentiality: What type of data does this asset store, process or access and how sensitive is the data? Consider the sensitivity of the data an asset handles. A system that stores customer PII or financial information would require a higher level of confidentiality due to the potential impact of unauthorized disclosure. In contrast, a system that only contains publicly available information would typically have a lower confidentiality requirement.  

• Integrity: How important is the accuracy and reliability of the data or functionality this asset provides? Think about how accurate and trustworthy the data must be. A production system that supports activities such as account balances or loan processing needs higher integrity because errors could lead to significant operational or regulatory issues. A development or testing environment, where data is not used to make real business decisions, may have a lower integrity requirement. 

• Availability: How essential is continuous access to this asset for daily operations? Evaluate how essential the asset is to uninterrupted operations. A customer-facing online banking platform generally requires higher availability, as downtime directly affects users. An internal tool used infrequently or for non-critical tasks may have a lower level of availability.  

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. 

Identify Threats to Each Asset

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. 

Evaluate Likelihood, Potential Damage, and Risk

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. 

Identify or Strengthen Controls

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.  

• Administrative, like policies and training 
• Technical, like multi-factor authentication, logging, and encryption 
• Physical, like door locks or alarm systems 

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. 

Develop the Risk Management Plan

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. 

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. 

Document, Review, and Update

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: 

• The assets you assessed.  
• How you determined criticality. 
• The threats and vulnerabilities identified. 
• The rationale behind likelihood and potential damage ratings. 
• The controls in place. 
• Any decisions to accept, mitigate, transfer, or avoid risk.  

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. 

Final Thoughts

When you step back, the core of an asset-based risk assessment is actually very simple. It comes down to four key actions: 

1. Identify what you're protecting. 
2. Understand what could compromise it. 
3. Determine the significance of that risk. 
4. Decide how to manage it. 

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.