Cyber incident recovery becomes real when normal systems stop working and the business has to decide what happens next.
Customer records may be unavailable. Staff may lose access to email or shared systems. Phones, payments, production or remote access may be affected. Several suppliers may be involved, but the business still needs one clear recovery order and people with authority to act.
The difficult question is not simply, “Do we have backups?” It is, “Could we restore the minimum operation the business needs, in the right order, with the information and people available?”
The National Cyber Security Centre’s new article on helping organisations recover when cyber attacks happen introduces a framework covering the first hours, recovery to minimum viable operations and the longer-term rebuild. Its related guidance explains that a highly disruptive attack can prevent normal operation. Recovery may take weeks or months and can require system rebuilds, redesigned business processes and temporary workarounds.
For an SME, that makes recovery an operational management issue as well as a technical one. The preparation needs to happen before the organisation is trying to make urgent decisions with incomplete information.
If the infrastructure map, monitoring scope or backup responsibility is already unclear, reviewing the managed foundation behind the business is a useful first step. Sentinel provides a route to discuss how 1Connect manages infrastructure, networking, security, Wi-Fi, servers and monitoring as one environment.
Table of Contents
Recovery is not the same as having a backup
A successful backup is useful evidence, but it does not answer every recovery question.
The backup may contain data without providing the full configuration needed to rebuild a service. One restored server may still depend on connectivity, firewall rules, identity services, storage or another application. The person who can restore the system may not be the person authorised to decide which service returns first.
The NCSC’s small-organisation guidance on backing up your data makes two practical points: organisations should know how to restore a backup, and they should check that it contains their important data.
That distinction matters. A backup process can complete every night while the real recovery route remains unclear.
The following five checks turn a general recovery intention into practical business questions.
Five cyber incident recovery checks for UK SMEs
1. What is the minimum operation the business must restore?
Trying to restore everything at once can make priorities less clear. Start by defining the smallest workable version of the business.
Ask which services must return first to protect customers, revenue, safety or contractual commitments. Depending on the organisation, that might include:
- a way to receive and respond to customer enquiries;
- access to current orders or job information;
- payment or invoicing capability;
- a production or warehouse process;
- connectivity between key sites;
- hosted voice or another agreed communications route;
- access to essential records.
This is the practical meaning of minimum viable operations. It is not a promise of normal service. It is the agreed level of operation the organisation needs while wider recovery continues.
Write the first three services down in order. For each one, record what it depends on. If the first service cannot run without a second system, network connection or supplier, that dependency belongs in the recovery plan too.
2. Who can make recovery decisions under pressure?
A disruptive incident creates decisions that may carry operational and financial consequences.
Someone may need to isolate a system, stop a process, approve a temporary workaround, authorise a rebuild or decide that a service should remain offline. Waiting for an unavailable director, an unrecorded supplier contact or an informal chain of approval can extend disruption.
The business should know:
- who leads the operational response;
- who can authorise technical action;
- who decides the order of restoration;
- who can approve temporary working arrangements;
- who communicates with staff, customers and suppliers;
- who records important decisions and changes.
These roles do not all need to sit with one person. They do need to be named, understood and covered when the usual owner is unavailable.
A short decision table is more useful than a plan that says only “contact IT”. It should connect each important decision to a named role, an alternative contact and the supplier or internal team needed to act.
3. Can the backup be restored into a usable service?
A backup should be treated as something to recover from, not only something to monitor.
For each important service, ask:
- What exactly is backed up?
- Where is the backup held?
- Who can access it?
- What equipment, software, credentials or configuration are needed to restore it?
- When was a restore last checked?
- How will the business confirm that the restored data is complete enough to use?
Some systems may use online backup. Others may use on-site or separate storage. The right arrangement depends on the service and risk. The essential point is that the recovery route is documented and can be checked without relying on one person’s memory.
A restore check should also reflect business use. Opening one recovered file does not prove that a complete service, its permissions and its dependencies will work as expected.
Mid-article action: choose one business-critical service and trace the full route from backup to usable operation. If the route depends on unknown credentials, undocumented configuration or an unavailable supplier, record that as a recovery gap now.
4. Which infrastructure dependencies could block the rebuild?
Recovery rarely happens inside one isolated system.
A server may need working storage, switching, firewall rules, name resolution and internet connectivity. Remote staff may need VPN access. A cloud service may still depend on local identity, network or communications arrangements. A restored application may need a database, licence, integration or data feed before users can work.
This is where infrastructure visibility matters. The business needs a practical map of the foundation underneath its priority services:
- internet connections and failover where configured;
- routers, firewalls and switching;
- Wi-Fi needed for operational devices;
- servers and virtual machines;
- storage and backup locations;
- remote-access routes;
- links between sites;
- the supplier or team responsible for each managed component.
The map does not need to become a large architectural project. It needs to be current enough for someone to see what must be available before the priority service can return.
Monitoring also has a role. It cannot guarantee recovery, but it can provide evidence about the state of the managed infrastructure and help the responsible team identify which components need attention.
5. How will people communicate and coordinate recovery?
Normal communication tools may be affected by the same disruption as the systems being restored.
The organisation should have a practical way to reach decision-makers, staff and critical suppliers when usual systems are unavailable. That may include securely held contact details, an agreed alternative channel and a clear rule about who issues updates.
The recovery team also needs one shared view of:
- what is unavailable;
- what has been isolated or changed;
- which service is being restored next;
- which supplier owns each action;
- what temporary workaround is active;
- what has been tested before users return.
This reduces the risk of conflicting changes or several parties working from different assumptions.
Where responsibility is split between connectivity, firewall, Wi-Fi, servers, backup and applications, the business should be explicit about who coordinates the managed infrastructure. One accountable route for that scope does not replace every specialist, but it can reduce the time spent joining together partial answers.
What to record before an incident tests the plan
A useful cyber incident recovery record can begin with one page per priority service:
- business purpose;
- recovery priority;
- acceptable temporary workaround;
- system and infrastructure dependencies;
- backup location and last restore check;
- decision owner and deputy;
- technical contact;
- supplier contacts;
- alternative communications route;
- checks required before returning the service to users.
Keep the record somewhere the authorised recovery team can reach even if normal systems are unavailable. Review it when infrastructure, suppliers or critical processes change.
The objective is not to predict every incident. It is to remove avoidable uncertainty from the first recovery decisions.
Where 1Connect can help
1Connect’s Sentinel service is positioned around fully managed infrastructure, networking, security, Wi-Fi, servers, monitoring, firewall management and remote access. It includes 24/7 monitoring through a Network Operations Centre and backup and recovery options according to the environment and configured scope.
That does not make Sentinel a formal cyber incident-response service, and it does not guarantee a particular recovery time or outcome.
The useful commercial conversation is narrower and more practical: is the infrastructure foundation visible, monitored and managed clearly enough to support the organisation’s recovery priorities?
1Connect can review where infrastructure responsibility sits, what monitoring covers, which backup and recovery options are configured, and whether the current arrangement leaves important gaps between suppliers.
Your next recovery check
Start with one question:
If our normal systems stopped now, which three services would we restore first, and could we trace every dependency needed to make them usable?
If the answer is unclear, do not wait for an incident to expose the gap.
Speak to 1Connect about Sentinel and review whether a more visible, managed infrastructure foundation could support your recovery planning. The aim is not to promise that disruption will never happen. It is to make the infrastructure, monitoring and responsibility behind recovery clearer before the business is under pressure.
