|
This week, we continue our journey through the seven steps you can follow to build a risk management framework for information. We’ve already looked at how to identify important information that may be at risk in your organization, where to find the information and how to assess the risk it presents within its business context. If you’ve followed these steps, you know where the risks lie and how big they may be; the next step is to evaluate the risk treatments available to you. In step 3, we assessed the potential damage that could result from information being lost, stolen, altered or made inaccessible. To evaluate risk treatments, you’ll need to examine that potential damage—i.e., the inherent risk—in relation to your organization’s appetite and tolerance for information risk. All organizations have to be willing to take some risks in order to move forward; “information risk appetite” defines the maximum amount of risk your organization is willing to assume. One way to think about it is to ask yourself at what point the potential impact of lost, stolen, altered or inaccessible information becomes unacceptable to your organization. (Keep in mind that the cost can be expressed in a variety of ways: the type or number of information records; the financial cost to compensate customers, make up for lost revenue or remediate the problem; or something more qualitative, like bad publicity.) At the point where the inherent risk exceeds the organization’s risk tolerance, appropriate technical and organizational risk treatments must be implemented to bring the inherent risk down to an acceptable level. In evaluating risk treatments, as in the previous steps, documentation is key. Only by documenting what your organization is currently doing to control risk can you assess the effectiveness and shortcomings of those controls, and make informed decisions about how you will treat risk going forward. You’ll be documenting current technical risk treatments (such as authentication methods, encryption, application and device patching, and compliance with password policies), as well as organizational controls (such as employee security awareness and training, physical controls, employee hiring practices, third-party risk management, and security-related policies and procedures). To gather all this information, you’ll need to create questionnaires for the responsible parties of the IT infrastructure—i.e., the owners associated with applications, databases, data stores, web sites, devices and third parties—as well as for those individuals responsible for organizational controls. For example, you might ask application owners questions such as:
If it sounds like documenting controls is going to mean a lot of time and effort (both for you and for the people responding to your questionnaires), I’ll admit it can be quite a bit of work. But it doesn’t have to be—and it won’t be, if you make automation part of your process. Automated assessment feeds and other automated tools for collecting and recording relevant information can dramatically reduce the time and effort required to document and evaluate current risk treatments. (Also, because control information is constantly changing, you’ll have to refresh it going forward. Automation allows you to do that without having to start from scratch with each assessment cycle.) Ultimately, the goal of collecting all this information about existing controls is to establish what your organization is doing to control information risk—and how well it’s working. You’ll want to look not just at where the organization has controls in place, but also where controls are missing or not working properly, who’s responsible for them and what’s being done to address any problems. This information is your baseline for evaluating controls. For a deeper dive into the process of evaluating risk treatments, download the white paper 7 Steps to Build a GRC Framework. Information for Step 4 includes questions to ask to collect the information you need, a diagram of areas to evaluate and tools for collecting information about them, and a summary of what you should expect to know by the end of the process. The post 7 STEPS TO A GRC RISK MANAGEMENT FRAMEWORK—4: EVALUATE RISK TREATMENTS appeared first on Speaking of Security - The RSA Blog. |
