Information Security Risk Assessment Checklist

Overview

Risk assessments are used to identify, estimate and prioritize risks to organizational operations and assets resulting from the operation and use of information systems.

Risk assessment is primarily a business concept and it is all about money. You have to first think about how your organization makes money, how employees and assets affect the profitability of the business, and what risks could result in large monetary losses for the company. After that, you should think about how you could enhance your IT infrastructure to reduce the risks that could lead to the largest financial losses to organization.

Basic risk assessment involves only three factors: the importance of the assets at risk, how critical the threat is, and how vulnerable the system is to that threat. Using those factors, you can assess the risk—the likelihood of money loss by your organization. Although risk assessment is about logical constructs, not numbers, it is useful to represent it as a formula:

Risk = Asset X Threat X Vulnerability

Nevertheless, remember that anything times zero is zero — if, for example, if the threat factor is high and the vulnerability level is high but the asset importance is zero (in other words, it is worth no money to you), your risk of losing money will be zero.

There are multiple ways to collect the information you need to assess risk. For instance, you can: 

• Interview management, data owners and other employees
• Analyze your systems and infrastructure
• Review documentation

To begin risk assessment, take the following steps:

1. Find all valuable assets across the organization that could be harmed by threats in a way that results in a monetary loss. Here are just a few examples:
• Servers
• Website
• Client contact information
• Partner documents
• Trade secrets
• Customer credit card data

2. Identify potential consequences. Determine what financial losses the organization would suffer if a given asset were damaged. Here are some of the consequences you should care about:
• Data loss
• System or application downtime
• Legal consequences

3. Identify threats and their level. A threat is anything that might exploit a vulnerability to breach your security and cause harm to your assets. Here are some common threats:
• Natural disasters
• System failure
• Accidental human interference
• Malicious human actions (interference, interception or impersonation)

4. Identify vulnerabilities and assess the likelihood of their exploitation. A vulnerability is a weakness that allows some threat to breach your security and cause harm to an asset. Think about what protects your systems from a given threat — if the threat actually occurs, what are the chances that it will actually damage your assets? Vulnerabilities can be physical (such as old equipment), problems with software design or configuration (such as excessive access permissions or unpatched workstations), or human factors (such as untrained or careless staff members).

5. Assess risk. Risk is the potential that a given threat will exploit the vulnerabilities of the environment and cause harm to one or more assets, leading to monetary loss. Assess the risk according to the logical formula stated above and assign it a value of high, moderate or low. Then develop a solution for every high and moderate risk, along with an estimate of its cost.

6. Create a risk management plan using the data collected. Here are some sample entries:

7. Create a strategy for IT infrastructure enhancements to mitigate the most important vulnerabilities and get management sign-off.

8. Define mitigation processes. You can improve your IT security infrastructure but you cannot eliminate all risks. When a disaster happens, you fix what happened, investigate why it happened, and try to prevent it from happening again, or at least make the consequences less harmful. For example, here is a sample mitigation process for a server failure:

9. Event (server failure) → Response (use your disaster recovery plan or the vendor’s documentation to get the server up and running) → Analysis (determine why this server failed) → Mitigation (if the server failed due to overheating because of low-quality equipment, ask your management to buy better equipment; if they refuse, put additional monitoring in place so you can shut down the server in a controlled way)