Preparing for a cyber incident before anyone is on call

At 7 pm, the supplier reports suspicious activity and asks whether it can isolate a business-critical service. The IT manager is on a flight. The chief executive's number is in the corporate directory, which nobody wants to access from a potentially affected device. The contract does not identify an alternative approver.

This hypothetical situation contains no exotic technical failure. It is a failure of preparation. An incident plan needs to make the first safe decisions possible when the normal working arrangements are unavailable.

Decide who is allowed to interrupt the business

Containment can affect customers and staff. Define in advance who may authorise isolation, suspend access or stop an integration, and under which conditions. Give the response lead a deputy. A title without an available person is not an operational arrangement.

Separate actions the team can take under standing authority from those requiring executive approval. The boundaries should be clear enough for an external provider to use. Discuss situations where delay could materially increase harm and agree the escalation route when the usual approver cannot be reached.

NIST's incident response guidance places preparation within wider cybersecurity risk management, rather than treating response as an isolated document. That fits the management task here: authority, staffing and supplier arrangements need to exist before an incident plan is invoked.

Write the authority in language colleagues understand. A support provider should not have to infer whether shutting down a service is covered by a broad phrase such as reasonable security measures.

Build a contact arrangement that survives lost email

Keep an appropriately protected, accessible copy of essential contacts and initial instructions outside exclusive dependence on corporate systems. Decide who maintains it, how changes are distributed and how outdated copies are withdrawn. An offline runbook is useful only if the right people can find a current version.

Include the response provider, relevant platform suppliers, executive deputies and qualified legal or privacy advisers. If insurance is in place, have an appropriate adviser confirm the policy's notification and provider arrangements. Do not presume an existing IT supplier is automatically an approved incident provider.

Test the contact route without staging an emergency. Ask each organisation to confirm how an urgent request is received and authenticated. Record the answer and any contractual limitations. A generic support address and a promise of best effort may not support the response capability management thinks it has purchased.

Avoid storing passwords or recovery secrets casually alongside a widely distributed contact list. The runbook should explain the controlled route to authorised access, not create an easy collection of powerful credentials.

Agree the first information to collect

The first report will be incomplete. Give staff a short way to record what was observed, when it was noticed, which services appear affected and who is already involved. Distinguish an observation from an inference. A supplier's alert about suspicious activity is not yet proof that information has been stolen.

Preserve relevant records under the direction of competent responders. Avoid uncoordinated clean-up that could interfere with investigation. Staff should know how to report the issue without forwarding sensitive material to personal email or posting it in a broad chat channel.

Arrange a decision log and a responsible recorder. Capture actions, authorisations and the reasons based on information available at the time. The purpose is to support a coherent response and later review, not force responders to write polished minutes while urgent work waits.

An agreed update rhythm also helps. Executives need a route for asking questions that does not continually interrupt the people investigating. The initial update can state what is unknown and when another update is expected.

Keep legal and insurance decisions with the right advisers

For an organisation subject to relevant privacy obligations, a suspected breach can require prompt assessment. The exact duties depend on facts and applicable law. Have qualified advisers identify the relevant notification and assessment requirements in advance, then reassess them during the incident.

Do not paste a universal deadline into the runbook and assume it covers every regulator, contract and policy. Privacy, sector obligations and contractual commitments may differ. The response lead needs an adviser and an escalation mechanism, not a false sense that one timer resolves all obligations.

Similarly, insurance arrangements need a reading of the actual policy. Ask about notice, consent, engagement of providers and how the organisation should preserve records of expenditure. This is operational preparation, not advice that a claim will be covered.

The limits are explored further in what a cyber insurance questionnaire does not tell you.

Rehearse the unavailable-person problem

Use a short exercise in which the primary contact is unavailable, email is untrusted and a supplier needs approval to act. Require participants to locate the alternative contact and explain their authority. Do not accept the answer that someone would probably know the number.

Record each missing decision or dependency as assigned work. Then test the repaired step. A tabletop exercise that tests decisions rather than memory offers a fuller structure without turning the rehearsal into a technical examination.

A small team does not have to pretend it can staff a permanent internal response centre. It does need an honest arrangement for availability and escalation. Management should understand exactly what support exists after hours, what it costs and what remains a gap.