Don't wait for something to go wrong before you start classifying, assessing and mitigating the risks to your IT systems.
Mention "risk assessment" to most people and they'll think of Health and Safety, hazardous chemicals, working at heights and so on; quite right too. But businesses face many different types of risk, all of which should be actively managed. They include financial, personnel, facilities - and IT risks.
Ideally your IT risks should be managed as part of a broader, organization-wide activity; there's not much point knowing how to restore data if you've nowhere to work or all your staff are sick. But here I concentrate on the approach we take to risk management with our IT systems and data. Larger organizations may have dedicated staff and different methods, but what we do has at least made us proactive and prompted us to make many changes.
Classifying IT risks
Classifying IT risks may help prevent working in a piecemeal fashion and thereby missing significant risks. Any classification will be arbitrary but Table A shows what we adopted.
There is inevitably overlap between these categories; what matters is that risks are not overlooked.
We use a typical qualitative method similar to health & safety risk assessments, where a combination of likelihood and impact indicates the level of risk and the consequent need for control or mitigation. The framework is shown in Table B.
The resulting risk levels are then as shown in Table C.
Mitigation is about reducing the chances of something undesirable happening - or reducing the impact on the business if it does happen. The measures required will vary enormously, but the first thing we did was to agree an urgency rating (Table D) based on the assessed risk level.
The second thing we did was to set up an IT Risk Register - a document where we track past and current risk assessment & mitigation activity. (It started out as a spreadsheet but became unwieldy so was recently reborn as a simple Word document.)
Part 1 of the Risk Register describes the risk categories and typical generic risk mitigation measures. For each category there is a list of specific risk assessments, with links to the detail given in Part 2. This list allows a quick overview of completed, archived or in-progress risk management tasks, together with highlighting those due for review. (The review period is also arbitrary; too long and you might be exposed to new risks without realising it because of system or organisation changes; too short and you'll spend all your time on risk assessments marked "no change"!)
Part 2 consists of detailed risk assessments and the additional risk mitigation measures used, where applicable. Table E shows the template we use.
"Additional Controls" could include system changes, new procedures, policy changes or enforcement, or education. For example:
- System image backups as well as file backups
- Purchase of spare units
- Review of password policy
- Data leakage monitoring
- Acceptable Use Policy
- Improvement of system documentation
- Due diligence when selecting suppliers
At the time of this writing, there are about 45 risks in the Register. The most recent one, relating to remote access, only got added as a result of an incident and subsequent management discussion. Right now we're adding a new policy and procedure to help reduce the risk.
Finally, we carry out an annual review of the Risk Register to check for incomplete assessments or mitigation tasks, and to add new risks.
IT risk management needs to be an ongoing activity, not a one-off exercise. It begins with a framework, and this is the one that works for us.