Latest Business Continuity News & Insights | Inoni

Why You Need a Pen and Paper Backup Plan for Cyber Incidents

Written by Inoni | Oct 17, 2025

The UK government has issued a clear warning to business leaders. Organisations must be ready to operate without their IT systems. In its latest annual review, the National Cyber Security Centre (NCSC) strongly recommends that firms keep physical copies of their contingency plans and prepare for the possibility of total digital shutdown.

This is not a theoretical risk. Recent cyber attacks on Asahi, Marks & Spencer, The Co-op and Jaguar Land Rover caused empty shelves and halted production lines. These incidents show how quickly operations can unravel when digital systems are compromised.

Backups Are Not Enough

Recovering from backups is often the first response to a cyber attack. However, attackers are increasingly targeting backup systems too. If your IT Disaster Recovery Plan assumes backups will always be available, it may be time to rethink.

Firms should test whether their backups can withstand modern threat vectors. This includes:

  • Regular restoration testing under realistic conditions
  • Air-gapped storage for critical structural data
  • Clear understanding of Recovery Point Objectives and acceptable data loss
  • Ensuring backup systems are segmented from production environments
  • Validating that backup credentials are not shared with production systems

Pen and Paper: A Practical Necessity

The NCSC now advises organisations to store contingency plans offline or in paper form. These plans should include instructions for how teams will communicate without email and how operations can continue without digital systems.

In the past, reverting to manual processes was easier. Businesses were less reliant on automation and staff had experience working without IT. Today, that knowledge is fading as experienced staff retire. Many of our clients say the capacity recovered through pen-and-paper methods would be minimal.

Still, it might be worth considering, especially if it helps retain key clients or maintain essential operations. The key is to understand what manual fallback can realistically achieve.

Planning for Pen and Paper Operations

  • Identify every operational process that relies on IT or digital data, including production, logistics, finance and customer service
  • For each process, define a manual workaround that can be deployed in the event of a cyber incident
  • Determine the minimum staffing levels required to operate manually, and whether those staff have the necessary skills
  • Audit physical resources needed for manual operations, such as printed forms, analogue phones, fax machines, whiteboards and filing systems
  • Establish fallback communication methods:
    • Use mobile phones where available, but note that not all staff may be issued one
    • Consider analogue tools such as fax machines, landlines, two-way radios or printed contact trees
    • Identify key staff who can act as communication relays across departments
    • Prepare printed directories with emergency contacts and escalation paths
  • Explore outsourcing critical manual tasks to third parties with existing capacity
  • Quantify the level of output that manual operations could realistically achieve, and assess whether this would meaningfully reduce business impact
  • Evaluate whether manual fallback would help retain key clients or contracts, or whether a full IT rebuild would be more effective

Planning for IT Restoration

Clearly, you would also be rebuilding IT whilst operating manually. For many organisations, rebuilding IT may be the only viable path. It requires careful planning and prioritisation to ensure recovery is swift and structured.

  • Assess the integrity of your backups. Have they been tested under realistic attack conditions? Are they stored securely and separately from production systems?
  • Review your Recovery Point Objectives (RPOs) for each critical data set. Do they align with business expectations and tolerance for data loss?
  • Define the minimum viable IT environment needed to resume operations. This should be informed by your Business Impact Analysis and reflect what is essential to maintain continuity.
  • Identify which data sets should be stored offline or air-gapped to support rapid recovery. This might include system configurations, client lists, supplier contacts and operational templates.
  • Plan how to manage the backlog of data and transactions lost during the outage. Will you attempt to recover it, or allow IT to catch up while operations pause? If you are operating manually at the same time, how will that data be rebuilt digitally?
  • Develop a phased restoration plan. Which systems and services should be restored first, and in what order? Prioritise based on business criticality and interdependencies.
  • Consider external support. Have you identified vendors or partners who can assist with accelerated rebuild efforts?
  • Establish communication protocols for the rebuild phase. How will teams coordinate without email or internal messaging platforms? What tools will be available, and who will manage them?
  • Document all decisions and procedures in a runbook. This should include technical steps, escalation paths, fallback options and communication plans.

Writing It Down: The Runbook

All these decisions should be documented in a runbook. This is not just a technical document. It is a crisis management tool. It should include fallback procedures, IT rebuild plans, communication protocols and decision-making frameworks. When the worst happens, you do not want to be making it up as you go.

How to Write a Runbook for Cyber Incidents

  1. Start with the Scenario
    • Clearly define the type of incident (e.g., cyber attack, data breach) the runbook covers.
    • State how this runbook fits with your wider continuity and IT disaster recovery plans.
  2. Keep It Adaptable
    • Reference supporting documents (impact analysis, incident responses, continuity plans).
    • Make it clear that the runbook should be adapted to the situation, not followed blindly.
  3. Structure by Stages
    • Use clear sections for each phase: detection, response, escalation, recovery, communication, and review.
    • For each stage, outline the main objectives and actions, but avoid excessive detail—focus on what needs to happen, not every possible step.
  4. Assign Roles and Contacts
    • List key roles (incident manager, crisis leader, communications lead etc) and ensure contact details are easy to find.
    • Include alternates and out-of-hours contacts.
  5. Emphasise Communication
    • Provide templates for internal and external messages.
    • Advise on how to keep stakeholders informed, including staff, customers, suppliers, and regulators.
  6. Include Manual Workarounds
    • Suggest where manual processes might be needed if IT systems are down.
    • Provide detail on how these will be deployed.
    • Encourage teams to record manual transactions for later system entry.
  7. Recovery Milestones
    • Break recovery into milestones or timeframes (e.g., immediate, 1 hour, 1 day, 1 week).
    • Advise on how to track progress and adapt as the situation evolves.
  8. Supplier and External Support
    • Note which suppliers or external partners may need to be engaged.
    • Include insurance and legal contacts.
  9. Review and Improve
    • Recommend a post-incident debrief to capture lessons learned.
    • Advise on updating the runbook and continuity plans based on experience.

Tip:
Keep the runbook practical, concise and easy to follow under pressure. Use bullet points, checklists and clear headings. Make sure it is accessible in both digital and physical formats.

Testing the Runbook

A runbook is only useful if it works in practice. Testing should be part of your regular continuity exercises.

  • Run tabletop simulations with key stakeholders to walk through the runbook in realistic scenarios
  • Conduct live drills where teams operate without access to IT systems, using only the runbook and fallback tools
  • Test communication protocols, including analogue methods, to ensure messages reach the right people
  • Validate manual workarounds by having teams perform critical tasks without digital support
  • Review timing assumptions and recovery milestones to ensure they are achievable
  • Capture feedback and update the runbook based on what worked and what didn’t

Storing the Runbook Securely

The NCSC recommends storing contingency plans offline or in paper form. This is essential to ensure access during a cyber incident.

  • Keep printed copies in secure but accessible locations, such as fireproof cabinets or designated continuity kits
  • Store digital copies on encrypted, air-gapped devices not connected to the corporate network
  • Ensure multiple copies exist across different sites or departments to avoid single points of failure
  • Assign responsibility for maintaining and distributing the runbook to a named individual or team
  • Regularly audit the storage locations and update copies when changes are made

Resilience Engineering

The NCSC is urging firms to look beyond traditional cyber-security controls and embrace resilience engineering. This means building systems that can anticipate, absorb, recover and adapt. It is about planning not just for prevention, but for continuity and recovery.

Final Thoughts

Paul Abbott, whose transport firm KNP collapsed after a ransomware attack, summed it up well. It is no longer a case of if, but when. The call for pen and paper might sound old-fashioned, but it is practical. Cybersecurity needs to be treated like health and safety. It is not optional, not an afterthought, but part of everyday working life.

This is all part of your business continuity planning. If you need help reviewing your strategy, testing your backups or writing your runbook, get in touch.