Security and Resilience

    Emergency management and recovery

    By Redaktion techport.ai, IT-Beratung · Last updated on

    The decisive question in IT security is not how an attack is prevented but how long the company can work without its systems and how it gets back. In a ransomware attack it is typically not individual servers that are affected but the network, the directory service, the backup and the telephony. Anyone then looking for a plan that sits on the encrypted server has no plan.

    Emergency management is uncomfortable because it asks what can go wrong. It is at the same time the area where a few days of preparation decide over weeks of standstill.

    How you notice it

    • There is an emergency plan but it has never been exercised.
    • Nobody knows in which order systems have to come back up.
    • The contact details for an emergency exist only digitally, inside the systems that have failed.
    • It is not settled who may decide in an emergency when management is unreachable.

    Why this happens

    Emergency preparedness delivers no visible benefit in normal operation. It competes with projects that produce results and reliably loses that competition until something happens. On top of that comes the widespread assumption that an existing backup already constitutes preparedness. A backup is a precondition, not a plan. It does not answer in which order recovery happens, who informs whom, how work continues without IT, and when operations count as restored.

    How we go about it

    1. Determine critical processes and time targets. We clarify with the departments how long each process may be unavailable and how much data loss is tolerable. Those two figures drive everything else, including the requirements on backup.
    2. Write the emergency plan. We produce a plan that is usable in a real emergency: alerting, roles, decision paths, order of recovery, fallback procedures for working without IT, contact details and reporting obligations. The plan is also held outside your own systems and on paper.
    3. Exercise. We run exercises, from a tabletop discussion through to technical recovery in a separate environment. Only the exercise shows whether the assumptions hold, particularly the assumption about how long it takes.
    4. Review and improve. We evaluate every exercise and every real incident and carry the findings into the plan, the technology and the contracts. An emergency plan is a document with a version, not a one-off result.

    What you gain

    • A solid statement about how long recovery actually takes.
    • The ability to act in the first hours, when most mistakes happen.
    • Compliance with requirements from law, insurers and customer contracts.

    From our projects

    In the first exercise the estimated recovery time is almost always far too optimistic. The reasons are rarely technical: administrator credentials sit in a password vault that is itself affected, the order of systems is unclear, and the people who would have to decide are unreachable because their numbers exist only in the failed system. Those points can be fixed within days once they are known, and they only become known through an exercise. The second recurring finding: working without IT is rarely thought through in the departments. The question of how orders are taken for a day without a system belongs in the plan and is almost always forgotten in practice.

    Good to know

    For companies within the scope of the German BSI Act, business continuity and recovery are explicitly part of the risk management measures under Section 30 BSIG. Independently of that, preparedness is part of the duty of care of management: for a GmbH it follows from Section 43 GmbHG, for a stock corporation from Section 91 AktG with its explicit duty to maintain a monitoring system for developments threatening the company. Cyber insurers now regularly require a tested recovery, and in a claim the existence and effectiveness of the measures is examined. BSI Standard 200-4 describes an approach to building business continuity management that smaller organisations can also implement in stages.

    Häufige Fragen

    How often should we exercise?

    At least once a year a tabletop exercise with the leadership team and at least once a year a technical recovery of the most important systems. After larger changes to the infrastructure the technical exercise should be repeated, because every change alters assumptions.

    Should we pay in a real emergency?

    That decision belongs prepared, not improvised. Paying guarantees no recovery, finances criminal structures and can have legal consequences. Far more important is reaching a position in which the question does not arise: separate, non-overwritable backups and a rehearsed recovery. Anyone attacked should involve law enforcement without delay and check reporting obligations.

    Let us talk about Emergency management and recovery

    In a thirty minute first call we work out where your biggest lever sits and whether we are the right people for it.

    Further reading

    Back to the field Security and Resilience

    Sources