Cybersecurity & Operational Resilience

From Cyber Resilience To Operational Resilience: Why Boards Need To Think Beyond Security

A business can restore its systems and still struggle to serve customers. Resilience needs to be tested against the operation those systems support.

Critical services linked through shared dependencies and an alternative recovery route.

The systems are back. The business is still struggling.

Orders need reconciling. Customers are waiting for answers. A supplier connection is unavailable and the people dealing with the backlog are already exhausted.

It is quite possible for a technology recovery report to look reassuring while the operation remains under considerable pressure. That is why boards need to look beyond cybersecurity controls and ask what the business can actually continue doing when something goes wrong.

Cyber resilience is essential. Operational resilience brings the rest of the business into the conversation.

Start With What Has To Keep Working

A list of applications will tell you what the organisation runs. It will not necessarily tell you how long the business can manage without them.

Taking an order, dispatching goods, supporting a customer or paying employees may depend on several systems, external suppliers and a handful of people who know how everything fits together. The problem often sits in the connections between those things.

The starting point should be the service the business needs to deliver. Who depends on it? What happens if it stops? How long can the organisation operate at a reduced level before the consequences become unacceptable?

Those questions need operations, finance and the wider executive team involved. Technology can explain the recovery options. The business has to decide what it needs and what it is prepared to accept.

That is a considerably more useful discussion than asking whether every system has a recovery plan.

Understand What The Plan Is Relying On

Dependencies deserve proper attention, particularly where the organisation has grown through acquisition.

Different applications may share the same identity service. Two suppliers may depend on the same underlying platform. A process that appears well documented may still rely on knowledge held by one person.

Supplier assurance matters, but it needs to connect to the service being bought. A supplier can meet its own recovery commitment while leaving the customer unable to operate.

The practical questions are whether the plans fit together, whether responsibilities are clear and whether the proposed alternatives work at the volume the business requires. A manual workaround that handles a few transactions is not necessarily a way of running the operation for several days.

None of this requires an enormous mapping exercise before anything improves. Start with the services whose failure would cause the most damage and work through their dependencies properly.

Recovery Needs Business Decisions

Restoring systems in the order that is easiest technically may do little to restore the operation.

The business may need one particular service back quickly, even if several less important systems could be recovered first. It may need to accept a temporary manual check, operate at reduced capacity or keep a service offline while further security work is completed.

Someone needs authority to make those decisions. Waiting for an incident to decide who that person is creates an avoidable problem.

Agree who leads the response, who owns the recovery of each critical service and when the executive team or board needs to intervene. Include customer communications and the effect on staff, as well as the technical work.

The plan also needs a way of operating when normal email and collaboration tools are unavailable. Keeping the only copy inside the system you are trying to recover is an optimistic arrangement.

Test The Operation

A successful restore is useful evidence. So is an exercise showing that people understand their responsibilities. The next step is demonstrating that the business can deliver the service.

Follow a realistic transaction through the process. Remove a supplier connection or assume a key person is unavailable. Test the alternative process with the people who would actually have to use it.

Then look at the backlog. Getting a service running again does not clear the work that accumulated while it was unavailable. Recovery plans need to account for the effort, time and people required to get back to normal.

An exercise can produce a very tidy action log. The business gets the protection when the important actions are closed and the changes are tested. Leaving them open until the next annual exercise rather misses the point.

Give The Board Evidence It Can Use

A board needs to understand which critical services have been tested, what level of operation was achieved and where the organisation remains exposed.

That gives investment decisions some context. A proposed change may remove a fragile dependency, shorten recovery or allow the business to serve more customers during disruption. Explain that consequence rather than presenting another list of controls.

The NCSC’s board guidance is a useful reference for incident planning and exercising. The executive responsibility is to connect that work to the business.

The useful test is whether the organisation can keep delivering what matters, recover in an order that makes commercial sense and show that its plan works. A green technology dashboard is only part of the answer.

Related: Technology Value Creation Starts With the Operating Plan

START A CONVERSATION

Can The Business Keep Operating?

Can The Business Keep Operating?

Discuss with Tony which services the business must protect, how recovery should be prioritised and which decisions cannot wait.

Start a Conversation

TDS Consulting Services Ltd | Registered in England and Wales | Company No. 14693087 | Registered Office: Brookfield Court, Selby Road, Garforth, Leeds, England, LS25 1NB

Executive technology leadership · United Kingdom

Privacy