Disaster recovery assumes the infrastructure is damaged. A fiber line is cut, a datacenter loses power, a routing table corrupts. The plan is to shift the workload to a backup site and restore the enterprise services. Minimum viable command assumes the infrastructure is gone, or at least entirely untrustworthy. The commercial cloud is unreachable, the enterprise directory is offline, and the satellite constellation is jammed. The plan is not to restore services. The plan is to operate indefinitely at a degraded level.
Every operations center has a floor. Beneath the cloud-hosted dashboards, the real-time biometric feeds, and the synchronized logistics databases, there is a hard limit to what the enterprise can support when the network degrades. That floor is the minimum viable command. It is the smallest set of communications, identity, data, and tools that still lets a commander direct operations.
The floor is defined by the commander’s decision loop, not the IT service catalog. A commander needs to know who is available, what each unit is doing, what instructions have been issued, and which information is reliable enough to act on. A case-management system or a shared collaboration suite may support those decisions in normal operation, but they do not belong on the floor. A service belongs in the floor only if the work stops without it and it can still function when the services above it do not.
When the network fails, the enterprise architecture diagram ceases to be a map of capabilities and becomes a map of liabilities.
Consider a regional operations center during a transition exercise. The scenario dictates a total loss of external connectivity. The primary screens go dark. The staff moves to the backup systems. The command software loads locally, but the geographic information system fails to render. The map tiles are cached on the drive, but the application relies on an external API call to authenticate the user’s session before displaying them. The commander has a radio link to the field, but no map to reference. The system did not fail because of a missing server; it failed because of a licensing check or an identity handshake that could not reach a vendor’s server. A system that fails closed during a routine validation is not secure. It is a self-inflicted denial of service.
This is where hidden dependencies surface. Architects map the network routes and the database calls, but they miss the invisible strings. They miss the software-defined radio application that requires a cloud-based license check every thirty days, or the field messaging app that depends on a central directory for recipient routing even when operating in a peer-to-peer mode. If your fallback system requires a DNS resolution to function, it is not a fallback system.
Identity is the hardest part of the floor. You cannot authenticate against a server that no longer exists. In a degraded environment, bandwidth is too scarce to sync directories, and latency is too high for complex handshakes. Yet, issuing a command requires absolute certainty of who is issuing it. When the cloud identity provider disappears, the organization must rely on pre-positioned trust. This means hardware tokens with localized PINs, pre-shared symmetric keys, and applications configured to authenticate against a local, static database.
Loss of connectivity does not suspend the need to know who issued an instruction. But an offline identity needs an expiry rule and an exception rule. A roster issued before the outage may authorize someone whose access was withdrawn after the network dropped. The organization has to decide in advance how long it will accept that risk, who can override the roster, and how the override is recorded. A procedure that simply instructs staff to verify identity manually leaves a consequential security decision to the person on duty in the middle of an incident.
The floor is usually smaller and older than people expect. Commanders are accustomed to rich operational dashboards and live drone feeds. Minimum viable command strips this down to grid coordinates, status codes, and text bursts over high-frequency radio. Bandwidth poverty forces organizational clarity. You find out very quickly which data actually matters when you only have three kilobytes a second to send it.
The tools that earn their place on the floor are often the oldest, precisely because they were designed before continuous connectivity was an assumption. An older tool may earn its place because its failure modes are visible. A printed contact roster can be wrong, but a commander can see its issue date and ask for confirmation. A cached directory that appears current on a screen may hide its last successful sync. The argument is not for paper over software. It is for information whose age and authority remain legible when the systems that normally validate it are gone. Paper doesn’t crash. A grease pencil on a plotting board does not require a firmware update.
The enterprise always wants to own the minimum viable command. It wants to procure it, integrate it, and provide it as a managed service. The MVC must remain independent of the enterprise. If it relies on the enterprise patching schedule, the enterprise configuration management database, or the enterprise software distribution points, it will fail when those systems fail.
Vendors sell resilience as a feature. They pitch a seamless integration with the primary cloud environment, promising real-time analytics at the tactical edge, and point to a generic offline mode in an appendix. Offline mode in a modern enterprise application usually just means the application caches data in a local database until it crashes or runs out of memory. You cannot buy a minimum viable command. You have to build it from what you have, configuring existing assets to operate in isolation.
Maintaining the fallback systems requires a mechanism to update them without connecting them to the primary enterprise network. This requires a formalized process of physical media transfers and localized staging servers that exist solely to maintain the MVC equipment. The enterprise dashboard will show these devices as non-compliant and offline. The technicians maintaining the floor must ignore the dashboard.
Testing the floor is where most organizations fail. A rehearsal should remove more than the main network link. You do not test minimum viable command by simulating a network drop on the primary system and watching the failover scripts execute. You test it by powering up the MVC hardware in a shielded room or a remote field site and attempting to execute an operation.
Have a new duty officer arrive after sign-in stops working. Introduce a staff change. Inject a wrong entry in the local roster. Send two situation reports in the wrong order. Watch where people look for an answer and whether that answer is actually available.
The most useful output of that exercise is usually an exclusion. If a tool requires an unavailable administrator, an untested certificate renewal, or an upstream directory to do its essential job, it does not belong in the floor. The human element degrades faster than the hardware. If staff only use the fallback systems during an annual compliance exercise, their muscle memory remains tied to the primary dashboard. When the real incident happens, they will try to troubleshoot the dead network instead of executing the mission. The transition to the fallback tools must be drilled until it is mundane.
Eventually, the network comes back. Reconnection produces conflicting records before it produces a common picture. Several local logs contain corrections, duplicate incident numbers, and instructions that were superseded verbally. Restoration is a reconciliation job, not a switch flipped back to normal.
If local records cannot be brought into the enterprise system without erasing corrections or obscuring who made a decision during the outage, the organization has preserved operations but lost part of its account of them. Fallback records need provenance more than polish. An entry should show who recorded it, when they recorded it, when the event was reported to have happened, and whether it came directly from the source or through another person. Those distinctions matter when clocks disagree and messages arrive out of order.
A regional commander will eventually face two situation reports: one received by radio and written into a local log, the other displayed on a cached dashboard with a newer-looking timestamp but an unknown sync status. The commander must decide which report governs the next instruction, and the floor must provide a way to record that choice.
Minimum viable command is not a project with a completion date. It is a capability with an ongoing funding requirement. It changes with the mission. Directing field units, maintaining custody of evidence, and coordinating an investigation need different records and permissions. One organization-wide fallback package risks becoming another enterprise system that nobody can carry or keep current.
The floor is defined by the commander’s authority. What can they do without asking higher? What can be delegated? The minimum is not the least. It is the smallest set that still lets the commander command. Every organization has a floor, whether they have defined it or not.