Every company runs on a few things that mustn't fail: servers, a code platform, email, people with the right knowledge. Business continuity is about what you do when one of those is suddenly unavailable, and above all about working that out beforehand. Then you don't have to figure out how to respond in the middle of the outage.
Key idea: continuity is arranged before an outage, not during one.
What is a BIA? BIA stands for business impact analysis. In plain words: for every activity or service we really depend on, you work out how bad it is if it disappears and how quickly it needs to work again. For each service you ask a few questions, and three of them give us the key figures:
| Figure | Stands for | Question |
|---|---|---|
| MTD | Maximum tolerable downtime | How long can it be down at most before the damage becomes serious? |
| RTO | Recovery time objective | How quickly do we aim to have it back? |
| RPO | Recovery point objective | How much recent data can we afford to lose at most? |
The fourth question: which people, data, infrastructure and external parties do we need to get it running again?
Key idea: the recovery target is deliberately set below the maximum tolerable time.
The bigger the damage if we exceed that limit, the more margin we build in. We judge damage the same way as in our risk management: financial, contractual, legal, operational and reputational.
The analysis lives in the asset registry. We don't keep a separate BIA document. Whoever owns an asset that supports an essential service fills in the continuity fields in our asset registry: how critical it is, its risk level, MTD, RTO and RPO (where data loss matters) and any assumptions or recovery notes. A short justification helps, for example why a certain loss is acceptable. The asset owner is also the key person for recovery, and the supplier and type of access are already in the registry.
The Security Officer maintains the structure and checks at least yearly, and after major changes or incidents, that all critical assets were reviewed recently and the values are still realistic. The registry is also what you open during an outage, to see what's affected, how critical it is and which dependencies play a part.
The continuity plan. For each critical service the plan describes an alternative, so the objectives stay achievable. Our software isn't tied to a single hosting provider, for instance, and setting up a server is documented. If the platform for our code or deployments goes down, we can deploy manually in an emergency, but we'd rather postpone other changes because it adds risk. For email we have a fallback route. Plans like these are honest about limits: switching takes time, and getting approval for a new service does too.
When the plan kicks in. An outage is always an incident first, so our incident procedure applies. The continuity plan comes on top when:
- an incident affects a critical activity or threatens to exceed its recovery target;
- a critical supplier has a major outage;
- the office is unusable and working from home isn't enough;
- a serious security incident affects the availability or integrity of critical systems.
We then assess the impact using the registry. We activate the plan if downtime is likely to run too long, several critical services fail at once, the damage could be serious, or management asks for it. The incident gets a separate flag and everyone is told we're in that mode.
Recovering without giving up security. We confirm priorities from the BIA, choose a strategy per service and record who does what. The options are:
- Fall back on a spare.
- Restore from a backup.
- Rebuild elsewhere.
- Use a workaround.
- Temporarily pause non-critical processes.
First we make sure nobody is at risk and that an affected system is isolated, with logs preserved. Security rules still apply during an emergency: client data does not go into private tools, access control and multi-factor authentication stay on, and logging, encryption or login checks are only switched off with explicit approval from the Security Officer and recorded as a knowingly accepted risk.
Internally and towards clients we communicate factually and on time, without sharing sensitive details unnecessarily, and within our legal and contractual obligations.
Closing and learning. The Security Officer declares the end once critical services run within limits again and the rest can go through normal incident handling. Temporary infrastructure and temporary access rights are then cleaned up. Shortly afterwards we review the timeline, measures and communication.
At least once a year we practise the plan, as a discussion, simulation or real technical recovery test. This helps us know it works before we need it. What we learn from a review or exercise feeds into continual improvement: for continuity, this may mean changing BIA values, the plan or supplier agreements, with an owner for each change.