Tools designed automate risk assessment

A risk matrix breaks these out into separate scales and assigns numeric values to each level of probability and impact. This allows you to chart the values on a matrix and calculate the risk for each combination of values. On a color-coded risk matrix, the hazard will fall into one of three categories: low acceptable risk, high unacceptable risk and moderate risk. This lets you see where additional controls are required to reduce risk to acceptable levels, although it requires management to determine ahead of time what precise level of risk in the moderate region is unacceptable.

A decision tree is a less frequently used risk assessment tool, but it can still come in handy. How a Decision Tree Works: A decision tree presents a series of questions or choices that branch out into a variety of outcomes. For example, quality professionals in the food industry might use a decision tree to determine when a hazard requires a Critical Control Point CCP. The bowtie model is used to mitigate the risk associated with rare, high-impact events.

It was originally used by high-risk industries like chemicals and oil and gas, but today the bowtie model is spreading to other industries because companies see how helpful it is for visualizing a complex risk environment. How Bowtie Risk Assessment Works: The center of the bowtie diagram is the hazard or loss of control event under evaluation. On the left side are preventive controls, and on the right side are recovery controls that would mitigate the impact if it did happen. Quality Management.

Sustainability Management. Vendor Management. Work Observations. Get the level of configuration and customization you need. Forget one-size-fits-all. This is your way to do software.

By identifying hazards and assessing their risks, organizations can increase productivity, avoid injuries, and avoid costly incidents. Identify and manage hazards, perform risk assessments, and automate the important processes related to each.

Roll-up the data to get a global perspective and drill back down to see the local picture, examining each and every significant hazard along with implementation of controls.

An effective risk assessment informs proposed actions by focusing attention and resources on the greatest risks. Our HIRA solution provides robust reporting to easily analyze such risks and their controls. Quickly see the current status of all assessments and control-implementation projects. Never let risk assessments grow old and out of date. Define periodic reviews and ensure the risk owner reevaluates the risk in a timely fashion, enabling opportunities to implement state of the art technology as new controls when that is applicable.

Get out of the office and visit the worksite. Hazards can be identified and recorded from anywhere using a mobile device, including effortless photograph attachments.

You can also work offline, and sync whenever a connection is available. When connected, analyze data for trends and spot issues.

In other words, vulnerability is determined by design factors, by the slight or great variances from specification that exist in building of assets and by the operational factors to which the asset is subjected. Among the operational factors, we should include the creation and the maintenance of controls designed to reduce the vulnerability of an asset to one or more threats.

We might, for example, build a dyke around the riverfront data center, thereby reducing its vulnerability to flooding. In the context of risk assessment tools, there are two approaches to assessing the impact of vulnerability. One approach is to simply assess the current state of affairs, including any controls that may already be in place. In order to be used in an automated risk assessment system, vulnerability must be measured in the same units as risk.

As for risk, we need to state vulnerability in terms of the likelihood or probability of a given threat reducing the value of the asset by a given amount. The possibility for automating risk assessment is limited to cases where we can make or calculate such evaluations of vulnerability. There are several strategies for handling the extreme complexity of evaluating vulnerability. If we really cannot judge by how much a given threat will damage a given asset, we can assume that the full value of the asset will be lost.

The result will be an exaggerated assessment of risk. Perhaps this exaggeration could be mitigated by calibrating the final assessments, as long as we make the same error in evaluating vulnerability for all assets and threats. We may also work on calibrating our own estimates, rather than giving up entirely. Another strategy is to use historical data to determine how similar incidents in the past affected asset value.

The same possible errors discussed in evaluating the probability of a threat occurring should be taken account when extrapolating from the historical record.

A third strategy involves modeling the asset-threat relationship. Modeling has the advantage of abstracting and simplifying a potentially infinite number of sizes of threats. Let us take the example of a data center surrounded by a dyke of a certain height threatened by floods of different heights. A mathematical or statistical model may allow use to take into account complete ranges of dyke height and flood height and the resultant probable impact on data center value.

Once we have described the assets, their values and how they interact in systems; the various threats to each of those assets; probability that any given threat might attack any given asset; and the vulnerability of that asset to that threat, we need to calculate the risk.

I have already talked about voodoo assessments in my book, IT Tools for the Business when the Business is IT , where I refer to the strange habit of prioritizing tools on a short list using methods that have no relationship whatsoever to tool value. A voodoo assessment of risk is similar, in that it is based on completely arbitrary and unscalable magic numbers.

Such values are largely meaningless and are of no use in an automated system. Sticking pins in voodoo dolls is just as likely to give useable results. This is not the place to discuss in detail the methods by which risk should be calculated. Suffice it to recall that risk is a measurement of uncertainty. The standard output of the risk assessment discipline is a risk register which is, at its core, a list of prioritized risks.

An automated risk assessment tool will create and maintain that register. It will differ from a manually maintained register in terms of its completeness, accuracy and the effort required to maintain it. The register is likely to be many orders of magnitude larger than a manually maintained register, for the simple fact that manual work could not possibly create and maintain as many data as an automated tool.

The sheer amount of effort required to manage risk and document that management is itself a risk to the ability to comply with regulations. Of course, a risk assessment tool will not, by itself, document the existence and the effectiveness of any controls in place. It will, however, provide a more complete risk register and provide better justification for the needs for controls or, conversely, the lack of need for certain controls.

As long as the automated risk assessment tool is using state of the art data sources for threats; is accessing a well maintained configuration management system; and uses industry accepted algorithms for calculating risks, auditors cannot but accept the well documented conclusions of the need for controls.

The descriptions of those controls and their links to the risks themselves need to be documented as part of whatever risk management tool is used in parallel with the risk assessment tool. The risk management tool should build upon and update the same risk register maintained by the risk assessment tool.

Needless to say, both risk assessment and risk management may be integrated into the same tool. An automated tool should have an interface with a change management tool. The change management tool would send data about the proposed change, including such information as the CIs to be changed; the context in which the changes are to be made; whether the change involves new, modified or deleted components; when the change is planned although the final planning is apt to come after the risk assessment ; who is to perform the change, the expected value of the change, and so forth.

On the basis of these parameters and the other information known to the risk assessment tool, such as the infrastructure architecture, the threats to the components and systems concerned, and the vulnerabilities of the components concerned, the risk assessment tool would return a risk statement in the form described above. The change management actors, such as the CAB members, would then decide if the risk is acceptable or if additional controls are required before approving the change for implementation.

A business impact analysis performed in the context of service continuity management identifies the assets at risk the services and related assets and it makes an assumption about the vulnerability of the service to a theoretical threat. That assumption is that there will be a catastrophic loss of service. Its value will be reduced to 0. Defining strategies for restoring that service in case of catastrophic loss depend on both the BIA itself, as well as an assessment of the probability of that catastrophe.

This latter information may be provided by the risk assessment tool. The availability management discipline should play a significant role in the design of any IT system. At the very least, it should be aware of the availability requirements for the services delivered with that system; support the design of the system to meet those requirements and to conform with any architectural policies in place; and ensure that the means are available for measuring the availability of the services using the system as well as the components out of which it is built.

A more advanced availability management will also support the building in to the system of reliability, maintainability and serviceability. The appropriate design of a system requires finding the right balance between the design features described above and the cost of building, maintaining and operating that system. A critical factor in finding the right balance is the assessment of the risks to achieving a given availability level for a given architecture.

The risk assessment tool can support the simulations of different architectures as a means for balancing cost against availability. It should be noted that such tools do exist, although they tend to be limited in scope to specific levels in the technology stack, such as for the design of a data network. Risk assessment in the context of IT service management is one of those areas where technology is playing catch-up to process definition.

We have at our disposal a large variety of working methods and formal processes designed to assess and manage IT risk. And yet, the technology used to support those activities is still in the dark ages for many organizations.