At 6:40 a.m., a property manager cannot badge into the main office. The building engineer sees alarms from a supervisory workstation, while the IT team finds encrypted file shares and unavailable network management tools. This cyber recovery example shows why recovery is not just an IT exercise. In a connected commercial property, the same incident can affect tenant access, cameras, work orders, engineering visibility, vendor coordination, and the ability to make safe operating decisions.
The question is not whether a company has backups. The question is whether it can restore a known-good operating environment without reintroducing the attacker, losing critical building context, or waiting for five vendors to decide who owns the next step. Recovery succeeds when technical controls, facility operations, documentation, and accountable leadership work as one system.
The Scenario: Ransomware Reaches the Management Network
Consider a multi-tenant office property with a small on-site engineering team and centralized IT support. The building has card access, IP cameras, a visitor-management platform, a building automation workstation, networked UPS monitoring, shared file storage, and remote access used by outside service providers.
An employee receives a convincing message that appears to be a document request from a contractor. Their credentials are captured through a fraudulent sign-in page. The attacker uses those credentials to access a remote management account that has broader permissions than the employee needs. Over several days, the attacker maps file shares, collects configuration files, and moves laterally into the network-management environment.
The encryption event begins overnight. By morning, the file server is unavailable, network switches cannot be managed from the normal console, and the building automation workstation displays errors because it relies on shared authentication and name-resolution services. Physical access controllers continue operating locally, but the central badge-management application is unavailable. Cameras are recording, yet security personnel cannot easily search footage from their usual workstation.
Nothing has failed in isolation. The property is dealing with a recovery problem across connected systems.
What the First Four Hours Should Look Like
The first objective is containment, not convenience. Teams often make the incident worse by reconnecting systems too quickly, using unverified administrator credentials, or allowing an outside vendor to dial in before the scope is understood.
A disciplined response separates affected systems from the rest of the environment. The incident lead directs network staff to disable remote access, isolate suspect network segments, and preserve logs. Facilities identifies systems that require local operation or manual checks. Security personnel establish a temporary process for visitor entry, after-hours access, and incident logging. Leadership names one decision-maker for recovery priorities and one technical lead for evidence, containment, and restoration.
This is where fragmented responsibility creates downtime. The access-control provider may say the network is the issue. The network provider may say the servers are the issue. The server provider may say the compromised account belongs to operations. Those statements may all contain part of the truth, but none of them restore the property. Someone must own the whole chain of decisions.
Stabilize building operations before restoring convenience
Not every unavailable application has the same consequence. In this example, the building does not need its usual badge-management screen before it needs a safe and documented way to control entry. It does not need every historical trend chart before engineers need confidence that critical equipment is being monitored locally.
The incident team verifies which physical security devices can operate autonomously, which building systems have local controls, and which remote connections must remain disabled. If a critical system depends on an unavailable service, the team documents the manual operating procedure, assigns inspection intervals, and records every temporary change. This is slower than normal automation, but it is safer than guessing.
The Recovery Plan: Restore a Trusted Core First
A recovery plan should follow dependencies, not organizational charts. Rebuilding a file server while identity services, network segmentation, and administrator accounts remain untrusted only creates another target.
In this cyber recovery example, the organization restores in a deliberate sequence. First, it establishes a clean administrative environment using protected credentials and a separate recovery workstation. Next, it rebuilds core identity, network services, and logging from verified recovery copies. The team then creates clean network segments for business applications, building systems, security devices, and vendor access.
Only after those controls are validated does it restore applications and data. The access-control management application returns on a restricted segment. The camera-management workstation follows, with access limited to authorized security staff. The building automation workstation is restored only after its configuration, device inventory, and integration points are checked against known-good records.
This order can feel inconvenient to teams under pressure. It may delay a familiar dashboard or remote vendor session by several hours. The trade-off is clear: restoring fast without restoring safely can turn a one-day disruption into a repeated compromise.
Backups are only useful if they are recoverable
Many organizations discover too late that their backups protected data but not operations. A backup may lack current switch configurations, firewall rules, controller programming, camera maps, software licenses, service accounts, or the documentation needed to rebuild the system in the correct order.
A usable recovery capability includes protected copies of critical configurations, not just files. It also includes a tested method to access those copies when normal identity systems are down. If every backup console requires the same compromised credentials or network path as production, it is not an independent recovery path.
For connected buildings, recovery records should identify what each system does, where it resides, who administers it, what it depends on, and how it behaves if communications are interrupted. A facilities director should not need to reverse-engineer a telecom room or call three installers to find out which switch supports a life-safety-adjacent control network.
Validation Is Where Recovery Becomes Credible
A server that starts is not necessarily safe. A badge system that opens is not necessarily applying the right permissions. A camera platform that displays video is not necessarily retaining footage or using secure time synchronization. Recovery must include operational validation, not just technical completion notices.
The team tests the restored environment with the people who use it. Security confirms that authorized, revoked, and temporary credentials behave correctly. Engineering confirms that alarms arrive at the right destination and that local overrides remain documented. IT verifies segmentation, privileged access, logging, endpoint protection, and backups. Operations confirms that tenants can enter, staff can communicate, and open service requests have owners.
This is also the time to identify what changed during the outage. Temporary accounts, bypassed door schedules, locally stored files, emergency vendor access, and manual equipment settings can all become permanent risk if nobody formally closes them out. Every temporary control needs an owner, an expiration date, and a verification step.
A recovery acceptance checklist prevents quiet failures
Before declaring normal operations, the accountable lead should require evidence that the environment meets defined acceptance conditions. At minimum, the team should confirm that:
- administrative credentials have been reset and privileged access is limited to named roles;
- remote vendor access is disabled, reapproved, or rebuilt with current controls;
- network diagrams, device inventories, and configuration records match the restored environment;
- security, building, and business teams have tested the functions they rely on; and
- backups have completed successfully after recovery and can be accessed through the approved process.
The checklist is not paperwork for its own sake. It closes the gap between a system being available and an operation being defensible.
What This Example Exposes About Ownership
The root cause may be a stolen credential, but the deeper failure is often unclear ownership. Broad permissions were allowed because nobody regularly reviewed remote accounts. Recovery priorities were unclear because no one mapped technology dependencies to building operations. Documentation was incomplete because project turnover ended when installation was complete, not when the environment was proven supportable.
Those are governance failures. They cannot be fixed by buying another tool and hoping it covers the handoffs.
A practical recovery program assigns one standard across infrastructure, cyber controls, operational procedures, and vendor access. It gives every critical system a business owner and a technical owner. It defines recovery objectives in operational language: how long can this function be unavailable, what manual process is acceptable, and what evidence proves it is safe to return to service?
The strongest test is simple: run a recovery exercise that includes IT, facilities, security, and property operations. Do not limit the exercise to restoring a server. Simulate the loss of normal network management, centralized access control, remote vendor connectivity, and shared documentation. Then measure how long it takes to identify dependencies, make decisions, and safely restore the functions people actually need.
A recovery plan earns confidence when it works under pressure, with incomplete information and real operational consequences. Build that discipline before the next Monday-morning outage, when every disconnected system becomes someone else's problem.