Organizations of all sizes apply risk management to their operations. In larger ones, this will normally be through a formal Enterprise Risk Management (ERM) methodology. An ERM can ensure higher level risks are left to senior managers, with lower-level risk decisions delegated to qualified people (i.e. through experience and training). In smaller organizations that do not have an ERM (or do not consciously apply risk management principles) risks can be left to those who seem best qualified to understand them. This can happen in larger organizations too.

Why the formality?

In the past, organizations had been accustomed to applying their own approaches to risk, based upon experience. As an example: in the late 1970s/1980's I worked in a UK government office that tried to catalogue its decisions, in the hope that others in the organization would reference this resource whenever they came across the same sorts of risks.

In the United States, one major driver towards formalized risk management was the 2002 Sarbanes-Oxley Act. SOX was a U.S. legislative response to financial crises triggered by mismanagement in previously respected corporations. SOX became a milestone for risk management, because it set down legal requirements for some corporate decision-making. Specifically, it required accounts to be signed off by top managers, making them personally and legally accountable. To further cover the accounting side, SOX included new oversight of firms providing those services.

This increased emphasis upon the need for good governance that had to be demonstrated was a major incentive to the business world for ensuring formal management of risks. Yet risk management can be complex and confusing, undermining its purpose of ensuring risk is effectively regulated. Some of this complexity stems from the way that risk management is presented.

Risk Management for smaller organizations

The U.S government certainly wants smaller organizations to get inside a formal approach to risk management. The U.S Small Business Administration (SBA) sponsors a - free - training manual 'Risk Management for a Small Business', a good start point for organizations with less resources. Security does get a mention in this, but there is a particular need to ensure risk management principles are applied to InfoSec. That's because the advantages of new data technologies must always be balanced against the risks of using them. For example, a particular patient data gathering service might give a teaching hospital a business edge: but if it has vulnerabilities that might allow hackers to change patient data, it must be for senior business (and medical) managers to decide if (or how) it can safely be adapted to the hospital's use.

So, how do we apply and successfully present risk management security principles to organizations not used to a formal system of risk management. Or to those which already have one, but use a format that is not a good fit with InfoSec?

Integrate where possible

As ever in security, simplicity is the key. The best course is to integrate InfoSec risks within an existing, already proven system of risk management. But InfoSec professionals face challenges to ensure InfoSec risks are properly expressed within wider business risks.

Conversely, preventing InfoSec risk from being separated from wider business risks can be a running issue. For example, loss of customer data from hacking and use by employees of their own devices for company data should be considered as legal, not just security risks. Another negative outcome from a separation of InfoSec from other risks might be senior managers losing focus on InfoSec issues, perhaps (and wrongly) assuming those sorts of risks are covered by their InfoSec professionals: that could be you!

If you sense InfoSec issues are getting overlooked because of the background noise from other business concerns, seek out your natural allies in audit and compliance. Professionals in those trades will naturally be attuned to the need for managed risk and very likely will be as keen as you that InfoSec risks are not overlooked.

Where there is no formal risk management

Where there is no methodology, or one that does not support InfoSec risk, it could be down to you as an InfoSec professional to lead the way. This sounds daunting – but helping your organization adopt a coherent form of risk management can add real benefit when it comes to demonstrating good management of the full range of business risks. A great argument for introducing a structured method is to emphasize how it can confirm the business advantages of new technology, by addressing security drawbacks head-on. Remember though that organizations with a 'can do' approach may resist an emphasis on the hazards of InfoSec. More go-ahead managers might be better persuaded that risk management will help them identify the business advantages of new technology, while giving them the power to control the associated risks. You can tell them about some common options available to treat a risk, e.g. accepting it, reducing it (e.g. by adding new countermeasures) sharing it with others: or not taking the risk!

A risk management register: first steps

Initial identification and ranking of risks is probably the biggest task for any InfoSec risk manager. It will (and should) take up the lion's share of a risk management installation program. For smaller organizations, engaging managers to identify the risks, ranking these risks into an approximate order of priorities (based on impact and likelihood) then agreeing risk priorities within the organization – are the first steps.

Key points for explaining risks are the creation of clear headlines that can be tracked in future (e.g. 'legal compliance', for summarizing all issues about complying with laws) together with a list of actions that have been, and which ought to be taken to mitigate them.

It is likely that many risks will be identified, but a skilled and experienced InfoSec professional should be able to group those which overlap into logical blocks: aiming to have no more than twenty key risks is a good target.

Warning: getting full participation (and assent) of key managers to build an initial list of risks, can be difficult to manage and will certainly require both people and time organization skills to get right. As I've noted, managers can instinctively take their hands off problems if only the InfoSec risk manager seems to understand them. On the other hand, an inadequately explained security risk could be misdiagnosed by them as either too high or too low on the scale. So steering a path between these two points is a necessary skill for the production of a successful risk register of InfoSec risks. In my experience, over weighting risks is more common than underestimating them: in any case, managers must finally understand that they own the risks agreed, a point which legislation like SOX underlines.

Which methodology?

There are many opinions on the right methodologies for calculating the likelihood and consequences of risks. Several templates are available, using various methodologies: not all are free (e.g. COBIT 5) while some are more weighted towards security (e.g. the Octave family). Start with whatever works, that which is best grasped by your senior managers. Before gauging the merits of any particular methodology, the simple approach outlined above is usually best for gaining initial traction.

Follow through with good-looking, familiar visuals

Not all InfoSec people are skilled at presenting information in a coherent form that is easily grasped. But simple visual tools which can be updated easily are effective management tools, as well as useful props for persuading managers of the advantages of managing risks. Spreadsheets are the building blocks for this, though more imaginative visual dashboards will be welcomed by managers, so long as they really do capture fundamentals at one glance. On the other hand, over-fussy visuals can overwhelm busy managers and possibly alienate them from important concepts behind them.

Applying numerical and color-code (known as 'traffic light' or RAG, i.e. Red/Amber/Green) values will become more important as the system is embedded and managers need more visual assistance to assess their risks.

Next steps

Ensure risks are regularly reviewed by the senior managers responsible for them. Including risk management reviews at scheduled management sessions is the best way of doing this. But where time is limited, make sure the top risks do get reviewed regularly. Where there are doubts about what risks are priority, this is a good reason to review your method for assessing risk priorities.

Keeping risks up to date through regular review ensures that managers constantly assess progress on dealing with problems, as well as having frequent opportunities to change the priority of a risk (and thus the resources allocated to it).

Finally, be open to challenge. If your chosen method does not actually work, be ready to revise it. Sticking to a flawed process can jeopardize an organization's attitude to risk management, which will certainly store up problems later. It can also undermine the importance of InfoSec risks.