Business continuity plan for a software company: what it should contain

A business continuity plan records how you get back to delivering what customers pay for, within an agreed time, when an incident, an outage or the loss of a supplier stops normal work. For a software company it comes down to two numbers per service: how quickly it must work again (RTO) and how much data you may lose in the process (RPO). The rest of the plan is about how you meet those numbers.

Continuity plan, recovery plan and incident response plan

The three are often used interchangeably, but they do different jobs:

• The incident response plan describes how you recognise, assess and contain an incident.
• The disaster recovery plan describes technically how you restore systems and data.
• The business continuity plan sits above both: which services must come back first, within what time, who decides and how you keep working while recovery is under way.

A small company can combine them in one document, as long as each of those three questions gets its own answer.

What it should contain

The Dutch National Cyber Security Centre (NCSC-NL) names as the core of a business continuity plan its scope and objectives, criteria for activating and standing down, an incident response plan with roles, a communication strategy and plans for backup and redundancy. For a SaaS or hosting company that translates into:

1. Scope and objectives. Which services, customers and locations the plan covers.
2. Activation. When the plan comes into force, who decides that, and when you return to normal.
3. Results of the business impact analysis. For each service the RTO, the RPO and the minimum level at which you can keep operating for a while.
4. Scenarios and strategies. For each scenario the fallback or recovery approach.
5. Roles and decision making. Who leads, who decides on measures that affect customers, who stands in for whom.
6. Communication. Customers, staff, suppliers and regulators.
7. Supplier dependencies. Which external services you rely on and what you do if they fail.
8. Backup, redundancy and recovery procedures. References to the technical recovery plan.
9. Testing and maintenance. How and when you exercise and review the plan.

The business impact analysis and RTO/RPO

A continuity plan starts with a business impact analysis (BIA). You map your processes and services, identify which depend on IT, and estimate for each service what an outage costs in money, customer trust and contractual commitments. NCSC-NL describes the RTO as the target time within which a function, process or service must be operational again, and the RPO as the interval over which you may lose data at most.

An example of the outcome for a SaaS company. The values are illustrative; the right numbers come from your own BIA and your contracts.

Then check whether your backup frequency, your redundancy and your availability commitments to customers match those numbers. An RPO of 15 minutes with a nightly backup is a promise you cannot keep.

Scenarios

Do not describe every conceivable disaster, only the disruptions that actually hit your services. For a software company these are usually:

• loss of the cloud region or data centre the platform runs in;
• ransomware or another attack that makes systems or backups unusable;
• loss of a key supplier, such as identity management, DNS, email or payments;
• losing the one person who knows a particular system;
• a data breach, at your own organisation or at a supplier.

Supplier dependencies

A SaaS company depends heavily on others for its continuity. List the external services your production relies on, with for each supplier the availability commitment, the contact route during outages and what you do if that supplier is gone for a day. Watch for hidden dependencies: a status page or incident channel hosted with the same provider as your platform goes down at the same time.

Communication

Agree in advance who speaks for the organisation and through which channels, and prepare messages for customers. Include the legal deadlines that may apply to you. A personal data breach may have to be reported to the Dutch Data Protection Authority within 72 hours. If your organisation falls under the Dutch Cybersecurity Act (Cyberbeveiligingswet), a significant incident requires an early warning within 24 hours, a notification within 72 hours and a final report within one month. If you act as a processor for your customers, make sure they hear from you quickly enough to assess their own reporting duty.

Testing and maintenance

A continuity plan that has never been exercised is an assumption. Test at two levels: technically, by actually restoring backups and running a failover, and organisationally, with a tabletop exercise in which the team works through a scenario. NCSC-NL advises reviewing the effectiveness of measures periodically, for example once a year, and revising the plan when the organisation, systems or threats change.

How it maps to ISO 27001

ISO 27001 does not ask for a document called a business continuity plan, but several Annex A controls lead to one in practice. In our own words:

The plan connects to incident management (5.24 to 5.26) and supplier management (5.19 to 5.23). ISO 22301 is a separate standard for a business continuity management system. It is a useful reference, but you do not need it for ISO 27001. Under the Dutch Cybersecurity Act, business continuity, including backup management, recovery plans and crisis management, is part of the duty of care.

Putting the plan to use

A continuity plan only proves its worth when people can work with it. Keep it short enough to read during an outage, put contact details and decision rights at the top, and keep a copy outside the systems that might fail. Trustbird's free tabletop module can take an uploaded continuity plan as one of the documents its scenarios are built from, so you can see whether the plan holds up in an exercise.