Continuity of Operations Software: Turning a 200 Page COOP Plan Into Something That Works at 3am

Three in the morning, and the plan is on the drive that is down

A ransomware event takes the county's file services offline at 2:40am. The continuity plan is a 214 page document with appendices, and it lives on a network share that is currently encrypted. Somebody has a printed copy from two years ago in a desk drawer. The order of succession in that copy names a director who left in the spring. The alternate facility listed for the assessor's office was repurposed as a records annex last year. The recovery time objectives were set by asking department heads how quickly they needed their systems back, and every one of them answered immediately, so the priority list has forty first priorities.

Meanwhile the actual decisions are being made by whoever is awake, from memory, in a group chat. The plan is not being consulted because it cannot be consulted, and even if it could, the version on the drive is one annual review cycle behind the organisation it describes. This is the normal state of continuity planning, in organisations that take it seriously, staffed by people who are good at their jobs. The document format is the problem.

A continuity plan is a dependency graph pretending to be a narrative

Underneath the prose, the plan asserts a set of relationships. This essential function is performed by these positions, using these applications, which depend on these systems and these vendors, from this facility, with these vital records, and it must be back within this window or the consequence is this. That is a graph. Written as a document, it can be internally contradictory without anyone noticing: an essential function with a four hour recovery objective can quietly depend on an application whose own objective is three days, and nobody catches it because the two facts are ninety pages apart.

Modelled properly, that contradiction is a validation error the system raises the moment it is created. So is a position with no named successor, an application with no responsible owner, an alternate facility that has been decommissioned in the facilities system, and a vital record with no offsite copy. Continuity managers spend most of their year chasing exactly those gaps by email. The gap detection is the product.

Where Fusion, Castellan, Riskonnect and Veoci stop

Fusion Risk Management and Castellan are capable business continuity platforms with genuine dependency modelling, and if you are a mid sized private organisation they are a sound purchase. Two things push public sector and health system buyers away from them. The first is the commercial shape: continuity touches every department, so a platform priced per user across a forty department county or a multi campus health system becomes a large recurring line for software that most of those users open twice a year. The second is that the model is corporate business continuity, so the constructs that are statutory in government, orders of succession set by ordinance, delegations of authority with specific triggers and limits, devolution to a geographically separate site, vital records defined by a records retention schedule, get configured in as custom fields rather than being native.

Riskonnect approaches it from governance and risk, where continuity is one module beside many others, which suits an organisation buying the whole suite and is heavy if you are not. Veoci is flexible and many emergency managers already run other functions on it, so the continuity work becomes configuration inside their environment. That is a reasonable path, and the friction is the same one that appears elsewhere: the value here comes from binding to your personnel, facility and application systems continuously, and configuration platforms are happiest when data is entered rather than derived.

Bind the plan to systems you already run

• Personnel, from the human resources (HR) system, so an order of succession that names a departed director flags itself the week they leave rather than at the annual review.
• Applications and infrastructure, from whatever configuration or asset inventory the IT department maintains, so a dependency that has been retired or migrated shows up as a drift.
• Facilities and space, so an alternate site that has been reassigned cannot remain in the plan unnoticed.
• Vendors and contracts, so a dependency on a supplier whose contract lapsed is visible before the outage rather than during it.
• Records inventory, so vital records carry their storage location, format and offsite copy status.

The point of each binding is the same: the plan should decay visibly rather than silently. A continuity manager who receives a weekly digest of ten specific drifts will fix ten things. A continuity manager who receives an annual review cycle will send forty emails and get eleven replies.

Delegation of authority has to be operational, not narrative

Most plans describe delegation in a paragraph. Under an actual outage the question is sharp and immediate: who can authorise emergency procurement above the normal threshold, who can direct staff to relocate, who can declare the event, and what happens when the person with that authority is unreachable. Model it as a rule with a trigger, a scope, a limit and an expiry, and then let the activation record show who actually exercised what and when.

That record matters twice. During the event, it prevents the paralysis of nobody being sure they are allowed to act. Afterwards, it is the answer to the auditor and to the elected official asking who authorised a particular expenditure at 4am. Organisations that have been through a real activation always add this. Organisations that have only exercised usually have not thought about it.

Vital records are the half nobody funds

Essential functions get attention because they are the visible part of the plan. Vital records get a table. Yet the function cannot be performed without them: the deeds, the case files, the licences, the personnel records, the utility as built drawings, the ones that would take years to reconstruct if they are lost. Each one needs a defined format, a storage location, a copy that is not in the same building or the same cloud tenant, a restoration procedure someone has actually tested, and an owner who is a person rather than a department name.

Tie this to your records retention schedule rather than maintaining a second list, because a second list will diverge from the first inside a year. Then test restoration on a sample each quarter, and record the result, because an untested backup is a belief rather than a control.

Exercises are the only real data the programme produces

Everything else in a continuity programme is assertion. The exercise is the measurement. So capture it properly: what was tested, who participated, what actually failed, the recovery times observed rather than the ones planned, the corrective actions, an owner and a due date for each, and whether the plan was updated as a result. Then feed observed recovery times back into the objectives, because a function with a four hour objective that has never recovered faster than eleven hours in three exercises does not have a four hour objective, it has an aspiration and a documented history of missing it.

This is also what an auditor wants to see. Not a plan, which anyone can write, but evidence that the plan has been exercised, that gaps were found, and that they were closed.

What this costs and how long it takes

A first release covering the essential function and dependency model, succession and delegation, vital records, and the drift detection bound to personnel and application inventories runs $55,000 to $120,000 and ships in 10 to 14 weeks. A full platform adding exercise management with corrective action tracking, activation mode with role based task assignment, devolution and alternate facility planning, department self service plan maintenance and audit reporting runs $140,000 to $320,000 across 6 to 11 months.

The variables are the number of departments, since each one is a discovery conversation and a set of essential functions to elicit, and the state of the inventories you want to bind to. An organisation with a maintained configuration management database is a straightforward integration. An organisation whose application inventory is a spreadsheet last touched in a previous administration has an inventory project inside the continuity project, and it is better to admit that at the start than to discover it in week six.

When you should not build this

Do not build if you are small enough that one person genuinely holds the picture, if your plan is under fifty pages, or if your regulatory driver is a checkbox rather than a real audit. A maintained document and an honest annual exercise is proportionate and cheap, and buying software will not create the discipline you are missing.

Build when the plan spans dozens of departments, when statutory succession and delegation constructs have to be modelled rather than described, when the plan needs to reflect systems that change weekly, when you have failed an audit on currency, or when a real activation has already shown you that the document was not usable at 3am.

How to choose a developer

Ask them to model, on a whiteboard, an essential function whose recovery objective is shorter than one of its dependencies. If they show you how the system detects and surfaces that contradiction, they understand the assignment. If they show you a form for entering functions, you are commissioning a document with a database behind it.

Ask what they have integrated with human resources and configuration management systems, and how they will handle records that do not match, because a person in the plan who no longer exists in the personnel system is the most important record in the entire build. Ask how the system behaves when it is itself unavailable, because a continuity platform that depends on the infrastructure it is meant to help recover is a joke told at your expense: there should be an exportable, current, offline usable version of every plan, generated automatically.

Then settle ownership before kickoff, including the exported plans and the exercise history. At Digital Heroes the organisation owns the code and the data from the first commit. Start scoping by taking your three most critical essential functions and tracing every dependency to a live system of record. If any link in those three chains cannot be verified today, that is the project.