Keeping Your Business Running Through a Cyber Incident

Imagine that staff arrive to find they cannot access the system holding current orders. The website still works, but nobody can confirm what must be delivered today. Customer calls increase while the team searches emails and messages for a partial picture.

This illustrative situation shows why a security discussion cannot end with a list of protective tools. The business needs to know which work is affected, which information is trustworthy and who can decide how to continue.

Start with the activities that keep the company operating. These may include accepting orders, delivering a service, paying staff, handling customer support or meeting contractual deadlines. Their importance depends on the business and the timing of the interruption.

The NIST Cybersecurity Framework small-business guide connects cyber risk with organisational objectives, assets and responsibilities. For an SME, that means explaining security priorities in terms the operating team can assess.

Ask what happens if an activity stops for an hour, a day or longer. The answer should include customer consequences, financial exposure, contractual commitments and the practical difficulty of catching up. Do not assume every system has the same urgency.

Choose a critical business service and trace what it needs to function. Include information, applications, accounts, devices, suppliers and people.

For order fulfilment, the chain might include the ecommerce platform, order records, inventory information, staff access, shipping labels and a carrier connection. A backup of one database does not restore the service if the team cannot access the accounts or operate the remaining steps.

Keep the map understandable:

Review shared dependencies carefully. An email or identity account may support several apparently separate systems. A single administrator may hold access needed for both normal work and recovery.

Identify weak assumptions. “The supplier will restore it” needs an agreed service arrangement and a contact route. “The team can use a spreadsheet” needs a source of current information and a way to reconcile later changes.

The map should help the business decide where a failure would have the greatest effect. It does not need to catalogue every technical component before the most important gaps can be addressed.

Recovery objectives describe what the business needs after an interruption. They should be agreed with the people responsible for the work, then tested against what the systems and budget can support.

Two useful questions are how long the activity can remain unavailable and how much recent information the business could lose without unacceptable consequences. These are commonly expressed as recovery time and recovery point objectives. AWS’s business-continuity guidance connects those objectives with recovery planning.

Be precise about the activity being restored. A server running again is not the same as staff being able to process orders correctly. Recovery may require checking data, restoring access, reconnecting services and reconciling work performed during the interruption.

For a small service business, a temporary manual booking process may be workable if staff can access a reliable schedule and prevent double bookings. For another business, losing access to current stock or payment status may make manual operation unsafe or impractical.

Document the assumptions behind the target. Which staff are available? Does the supplier provide support at that time? Where are instructions and credentials held if the usual systems are inaccessible?

A recovery target is a business requirement until an exercise shows that the operating arrangement can meet it.

Prevention reduces the likelihood or impact of an incident. Recovery reduces the disruption when protection fails or a different event interrupts service. A cybersecurity plan should account for both.

Prioritise controls around the critical dependencies identified earlier. That may include stronger account protection, appropriate access, supported software, reliable backup arrangements and clear procedures for changes to sensitive information.

Do not treat backup as the whole recovery plan. Establish what is protected, whether essential copies are separated from the same failure conditions and how restored information will be checked. The detailed method depends on the systems and the business’s recovery requirements.

Review the information the company collects and retains. Unnecessary data creates exposure without contributing to the service. The FTC’s Start with Security guidance also addresses provider security and planning for incidents. Those are useful practical concerns when essential work depends on external tools.

Assign ownership to each priority. A control described in a policy but absent from normal work provides little confidence. Someone must be able to confirm that access is reviewed, updates are handled and recovery arrangements remain usable.

Sequence improvements by consequence and feasibility. A small business may need to repair a critical access weakness immediately while planning a more substantial recovery change. The aim is a defensible order of work, not a claim that every risk can be eliminated.

Run an exercise around a realistic interruption. Begin with the loss of one important service and ask the responsible people to explain their actions using the information they would actually have.

Who identifies the incident? Who can restrict access or pause affected work? Who contacts suppliers? Who decides whether the temporary workaround is acceptable? Who communicates with employees and customers?

Keep contact details and essential instructions available through an appropriate route outside the potentially affected environment. A response plan that can only be opened through a compromised account may be unavailable when needed.

Test the technical recovery where appropriate and safe. Record the time, missing information and decisions that delayed progress. Verify that the restored service supports the intended business task, not just that a file or system is present.

The exercise should also cover information integrity. If staff cannot establish which records are accurate, rushing to resume work can create further problems. Decide how the team validates the recovered state and handles transactions made during the interruption.

Notification and reporting duties vary by jurisdiction, sector, contract and incident. Identify the relevant requirements and professional contacts in advance for the markets and information involved. Avoid inventing a universal reporting deadline in the response plan.

Review the plan when the company changes a supplier, adds a location, introduces a critical system or gives a new service access to important records. Those changes can alter dependencies even when the business process looks familiar.

Include continuity in procurement. Ask how information can be exported, how incidents are handled and what support is available. Make sure the answers fit the needs of the activity the supplier will support.

After an exercise or actual interruption, assign actions to resolve the gaps and check completion. A lesson recorded without an owner can remain the same weakness at the next review.

The plan should leave the team able to identify what must continue, what can wait and how essential work will resume. Keep those decisions current enough to use during an interruption.