Understanding strategic risks in enterprise IT

The pressures on CIOs to enhance capability are significant. Their freedom of movement can be heavily constrained because of the current mix of enterprise IT systems and the challenge of keeping the business running while evolving.

There is always an upgrade to install, or new capabilities to incorporate. Some may be evolutionary, but others disruptive, with a number of issues to consider. The risks in managing today’s complex hybrid IT landscapes keep changing with unforeseen implications at every level.

The drive to the cloud also puts pressure on organisations to modernise mission critical applications. There simply isn’t time to replace them and discard years of investment. However, it is essential to understand the scope of change, what the endpoint looks like and put a plan together with the associated risks and strategies to manage them - to avoid business disruption and deliver success.

Understanding risk

So, what is risk? We can describe and quantify risk as follows... There is a probability of X happening. If it did occur, then the size of the impact would be Y. There are a range of possible events that can impact an organisation or a project and it is the role of a person responsible for risk in the organisation to balance these risks and plan to deliver the required outcome.

What’s the role of mitigation and contingency?

Having assessed probability and impact, we consider mitigation and contingency. Mitigation is the plan to spend resources to reduce the probability of something going wrong and the size of the impact if it does.

We cannot always influence the probability of some events, for example the chance of rain. But we can others. Regular servicing of a vehicle to prevent breakdowns is an example of mitigation to reduce probability. Mirroring a pair of disks is an example of reducing the impact of a failed disk.

In terms of managing IT system change, a great example of mitigation is keeping enterprise IT systems fully patched to the latest versions of software and firmware. Another is ensuring that release procedures of internal applications are proven and reliable. This means that the size of any subsequent change is minimised and staff are practiced at implementing change.

Nevertheless, ‘if it can go wrong - it will’ so costing, developing and practicing contingency plans is necessary, as despite our efforts at mitigating IT risk, some events will occur.

That means we need to assess the best balance between spending time and resources to:

• minimise the probability of an event occurring
• minimise the impact if it does happen
• prepare and test plans to recover from the failure (updating them from time to time as our systems change)
• review each of the events based on this probability

Risk versus opportunity

Opportunity and risk are two sides of the same coin. An organisation that manages its risks effectively also creates opportunities. It understands a problem better than its competitors and can estimate the likely cost and the time required more accurately. It can compete more effectively by giving customers confidence that it can deliver more reliably.

Efficiency drives down cost, effectiveness delivers an outcome closer to the estimated price and timescales, therefore delivering better profits where other competitors fear to compete.

The difference between operational and project risks

It is also worth reflecting on the difference between operational and project risk. Operational risk covers the inherent risks that may impact the organisation when it is carrying out its normal day-to-day business. It’s likely that many of these risks impact the organisation regularly and are ‘frequency risks’. We expect them and we take the mitigation and contingency measures to minimise the probability and impact of them when they occur.

For example, employees’ laptops fail, are stolen or start to run too slowly and have to be replaced. The impact on the business of the failure can be measured in the time the person cannot do their job and the size of the impact given to each person’s role. These risks, or elements of them, are often the type which can be insured against.

If an organisation is implementing change, then it is probably running a project that has a start and an end. The organisation may not have project or change management skills in-house. The principles of managing operational risk or project risk are very similar. The difference is that a task might only be performed once on the project and risk management is about strategies to achieve the same outcome by a different path if a task fails. Insuring against project overruns is a less common strategy.

IT system risk assessments

When risk assessing critical IT systems, the first question to ask is ‘Do we have the skills to perform such a review?’ The organisational challenge is to ensure that the reviewers are supported to perform with integrity and candour. Standard risk categories exist which can be used to analyse an organisation’s risk profile. These provide checklists of what to consider and offer a starting point to identify any unique risks. Another option is to use external consultants to perform some of the work, with a hybrid approach perhaps being preferable.

Help is at hand

There are some well-respected enterprise IT frameworks which provide structure for IT reviews. Probably the best place to start is by assessing the level of IT security risk in your organisation using Cyber Essentials from the National Cyber Security Centre (NCSC). Five broad system security controls are covered:

• firewalls
• secure configuration
• user access control
• malware protection
• patch management

The NCSC site also offers advice on how to address data protection issues. Non-compliance with data protection rules (GDPR) can be a major risk to an organisation and needs to be treated seriously as large penalties could result if data breaches occur.

Today’s critical cybersecurity risks

Too often, the response to cybersecurity risk is a head-in-the-sand, ‘that won’t happen to us’ attitude. The sophistication of attackers continues to evolve. If they find a successful target, they regularly repeat the attacks. The following three cybersecurity risk areas currently impacting organisations:

• ransomware
• mandate fraud
• theft of commercial data by employees intending to leave the company

Organisations can make rapid progress by using the IASME framework for Cyber Essentials or the more rigorous ISAME governance. It guides the organisation to do the simple things immediately and then develop defences over time using a simple questionnaire, where if the answer is ‘no’, then it is a fail but the improvement plan is clear. The most vital starting point is staff awareness and training.

The risk of third party IT vendors

Most organisations are now largely reliant on systems and technology written by third-party vendors that are experts in their fields. This has removed one set of risks but has introduced other types of risk through reliance on those technology vendors, especially as critical systems age. Risks include:

• vendor financial stability
• technology end-of-life
• unattractive commercial terms.

Be aware of the vendor risk pitfalls

If a vendor went out of business, the software it provides might no longer be supported and future updates might not be developed. Bugs and vulnerabilities that were subsequently identified might not be fixed. The software may no longer function on replacement hardware or operating systems. Integrations to other vendors’ systems which are still being upgraded may start to fail. There may be no alternative other than to rip out the system and replace it.

The same drastic action may be needed if a software vendor ‘sunsets’ a product if it’s no longer profitable or supportable. The vendor may offer a more up-to-date alternative and provide a migration path from the end-of-life product to its replacement. However, organisations may be forced to make significant expensive changes such as knock-on upgrades, rewriting interfaces, testing and even business interruption.

Changing commercial terms of your software

The original commercial terms for the use of software may be changed unfavourably over time. If a vendor ‘sunsets’ a product or if customers stay on an old version, often for good reasons, they may be faced by vastly increased and annually rising charges for support, subsequent upgrades, services, etc.

Often ‘great deals’ attract substantial discounts which might not be offered subsequently on renewal once the customer is hooked. An unlimited usage model might revert to standard per-user. Discontinuing a concurrent user model and reverting to a named user model, when a customer has hundreds of infrequent users sharing a small number of concurrent users, will cause costs to skyrocket.

The customer’s own changing circumstances might drive a need for a change in terms that is refused. The business might have been sold or downsized, so that the favourable deals open to large enterprises may no longer be offered.

Protecting your critical IT solutions

An organisation needs to keep itself in a position of maximum flexibility with as many options as possible for change or for keeping the status quo. Awareness of the potential lock-ins which leave a business over-reliant on a particular vendor or bind it into using a particular solution, is of paramount importance.

Here are some tips to minimise the lock-ins:

• architect solutions as components and limit all interaction with a product via your own APIs to that component, so that change when replacing a product is limited to that component (a simple example is for all SQL to be placed in stored procedures, which keeps vendor-specific SQL out of the code, and the scope of change is limited to porting those procedures)
• look for solutions which use open-source offerings
• favour applications which use open APIs.

Does every cloud have a silver lining?

To mitigate some of the lock-in pitfalls, it may seem attractive to migrate existing solutions to the cloud or move to new cloud applications. However, organisations need to be aware that such a course of action can introduce new traps and handcuffs.

For you

Be part of something bigger, join BCS, The Chartered Institute for IT.

A cloud platform such as AWS, Azure or Google offers a very rich set of facilities, capabilities, security, interfaces and APIs for all aspects of a deployment and run time environment.

It’s almost too attractive and tempting - but once you’ve put all your eggs in one basket, what if a particular vendor gets hit by a cyber attack, hikes prices or data storage rules change? It seems sensible to develop a strategy, or at least an awareness, to facilitate the ability to easily migrate solutions between the major cloud vendors and others which might emerge.

A well known vendor offers an enterprise IT solution that takes your artefacts and can deploy them into any of the cloud environments, but now you are locked into the vendor’s deployment product. It’s about balancing risk.

Do yesterday's IT templates and plans still apply?

Over the last decade, many large and medium sized organisations have created comprehensive IT plans which are sitting on the shelf waiting to be actioned. In IT, there is constant evolution. Cumulative changes and unexpected combinations of solutions can drastically affect assumptions and plans.

Business continuity and disaster recovery illustrates the need for change. 15 years ago, a multi-million-pound alternative data centre, together with provision for temporary office space, might be essential for BC/DR. Now, Office 365 and AWS - plus the lessons from successful pandemic home working facilitated by Teams and Zoom - provide the potential to enable us to rewrite these plans and drive down costs. This is a very clear example of risk and opportunity.

In IT, while the basic engineering principles are largely unchanged, the technologies by which they are delivered can change rapidly. Become a chartered engineer through BCS and embrace those long-lasting principles rather than focusing on a particular AWS, IBM or Azure technology qualification with a limited lifetime before its replaced.