Cyber Incident Response: When Systems Go Down

The short version

A cyber incident is a continuity problem before it is a technical one. The question on the first morning is not how the attacker got in. It is whether you can still take a call, dispatch a unit, alert a station, document a patient and pay your people, and for how long you can do all of that on paper. Most departments discover their real dependencies during the outage. Station alerting turns out to run through the same network as email. The pre-plans are in a cloud system nobody can reach. The ePCR queues locally but cannot transmit, so the hospital gets nothing. Payroll is a city system, and the city is also down. Restoration is a command decision, not an IT one. Someone has to say what comes back first, and that order should be written before the incident, not argued during it. Dispatch and alerting almost always lead. What follows them depends on your operation, and the useful exercise is to put the list in order now, with the people who would have to live with it. Recovery is also staged rather than instant. Systems come back partially, in a rough order, sometimes into a rebuilt environment, and a department can spend weeks operating in a mixed state where some things work and some do not. Plan for the mixed state, because that is where most of the time is actually spent. For EMS there is an added layer. Patient information is protected health information, and an incident touching an ePCR system brings notification and privacy obligations that run in parallel with the operational response. Know before the day comes who makes that call in your organisation. None of this is an argument for alarm. It is the same reasoning behind a pump failure plan or a mutual aid agreement: decide in advance how you keep working when a thing you rely on is unavailable.