Virtual CISO · Business continuity
Know which processes you cannot lose, and for how long
Continuity planning goes wrong in a predictable way: it starts from systems. Somebody lists the servers, decides they are all important, and produces a plan that protects everything equally and therefore nothing in particular. Starting from the business and working back is slower, and it is the only version that survives contact with a real outage.
The processes the organization is actually made of
Order intake, payroll, dispatch, patient admission, settlement — whatever the handful are without which your organization is not operating. Each one gets an owner by name, a type, and a judgment of how bad it is when it stops.
Then the two numbers everything else hangs on. The recovery time objective is the target time for getting the process running again after it stops. The recovery point objective is how much recent work you can afford to lose, expressed as a stretch of time — an hour of it, or a day. Most organizations have never written either down, and the two people who would answer differently have never been in the same room.
- A named owner per process, because a process owned by a department is owned by nobody at two in the morning
- An impact rating that distinguishes inconvenient from existential, rather than marking everything critical
- A recovery time objective and a recovery point objective, agreed rather than assumed
- An estimated monthly loss if the process is unavailable, which is what turns this from an IT document into a business one
What each process depends on, and therefore what matters
Only once the processes are ranked does the question of systems become answerable. Each process is linked to the applications, data and suppliers it needs, and the priority of a system becomes a consequence of the processes behind it rather than a matter of whoever argues hardest for their own.
This is also where the uncomfortable discoveries happen. A process that has to be back within four hours and can afford to lose no more than four hours of work, depending on a system backed up once a night, is not a plan but a contradiction — the restore can finish in time and still hand back yesterday. It only shows up when both numbers are written next to each other.
The tasks that make the numbers true
An objective nobody has worked towards is a wish. Each process carries the tasks that would actually make its recovery targets achievable — tested restores, a documented failover, a supplier contract with a matching commitment, an alternate process somebody has rehearsed — and those tasks sit in the same list as everything else, competing on the same priorities.
The useful consequence is that continuity stops being an annual document exercise and becomes a visible part of the plan, with the same owners, dates and evidence as the rest of the security program.
A business impact analysis, and a continuity plan you still have to finish
The impact analysis is a document in its own right: the processes, their owners, their recovery objectives, their dependencies and the estimated loss, in the form an auditor or a certification body expects to receive it.
The continuity plan is a template pre-filled from that analysis — and it is a template, which is the honest word for it. It carries your processes, your objectives and your dependencies rather than a generic example, which saves the part everybody gets wrong. What it cannot carry is a rehearsal. A continuity plan becomes a plan when somebody walks through it, finds the three steps that do not work, and fixes them. Until then you have a very good draft, and we would rather tell you that now than have you discover it during an incident.
Estimated loss, as a figure somebody can act on
Adding up the estimated monthly loss across the processes you have mapped gives a single figure of exposure. It is an estimate built from your own numbers, and its value is not precision — it is that it is denominated in the same unit as the budget being asked for.
A security case made in terms of likelihood and severity gets a polite hearing. The same case made as "this much a month rides on processes we cannot yet recover inside their own targets, and this task list is what changes that" gets a decision.
Continuity is not optional under the directive
Article 21(2)(c) names business continuity — backup management, disaster recovery and crisis management — among the measures in-scope entities must have. It is not satisfied by having backups. It is satisfied by being able to show that you know which processes matter, what their recovery objectives are, and that somebody has tested whether you can meet them.
Which means the work on this page is the same work the audit asks for, counted against the same task list as everything else rather than run as a separate project with its own documents and its own deadline.
Frequently asked questions
The questions we hear most often from security and IT leaders.
Something not covered here? Ask us directly
Not yet, and we would rather tell you now. What comes out of the impact analysis is a plan pre-filled with your processes, your recovery objectives and your dependencies — which is the part everybody gets wrong, and a long way ahead of a blank template. What it has not had is a rehearsal. A continuity plan becomes real when somebody walks through it, discovers the three steps that do not work, and fixes them. We can run that exercise with you; what we will not do is hand you a document and call it a tested plan.
You do, and specifically the person accountable for the process rather than the person who runs the system underneath it. This is the conversation the analysis exists to force: IT can tell you what is currently achievable, but only the business can say how quickly the process has to be back and how much recent work it can afford to lose. Where the two answers disagree — four hours of tolerable data loss against a nightly backup — that gap is the finding, and it is usually worth more than the document.
Backups are necessary and they are not continuity. A backup answers whether the data still exists. Continuity answers whether the business can keep operating while you restore it, and for how long it can wait — which depends on things a backup policy says nothing about: who declares the incident, which process runs manually in the meantime, which supplier is on the critical path, and whether anyone has ever tested the restore end to end. Most organizations discover the gap between the two during the event.
Where this sits, and what comes next
Scanning
What an attacker sees from outside, what the directory looks like inside, monthly.
Board reporting
The monthly pack: scores, movement, and one slide a board will actually read.
Ready to get started?
Partner with Spirity Enterprise to implement the right security and IT solutions for your organization.