Facility continuity ·
When the Office Internet Goes Down: A No-Guessing Plan for Self-Storage Managers
A disconnected office does not make every facility system unavailable. Put each service into a named operating state, protect customer information, and reconcile every deferred action after the connection returns.
The first mistake during an office internet outage is treating the whole facility as either “open” or “down.” The second is improvising.
A self-storage manager may lose access to the browser, email, online rental tools and payment portal while the gate controller continues to admit authorized customers. A local camera monitor may still display live video even though remote viewing is unavailable. The office phone may work, fail or route through a separate service. Each function has its own dependency and its own safe fallback.
The manager’s job is not to diagnose the network from the front desk. It is to establish what is directly observed, protect people and customer information, assign an operating state to each service, and keep a clean record of work that must be completed later. That is how a routine connectivity problem stays a controlled interruption instead of becoming a payment, access or customer-service problem.
Start with the facility, not the router
An internet outage can result from a local equipment problem, an internet-service-provider interruption, a building power issue or something else. It should not be labeled a cyber incident without evidence. The first operating check is simpler:
- Are life-safety systems and emergency communications available?
- What is directly observed at the office workstation, phone, payment terminal and local control panels?
- Which customer services depend on the lost connection?
- Which local systems still function without it?
- Who owns technical diagnosis and restoration?
If there is smoke, a life-safety alarm, damaged electrical equipment, heat, odor or another physical hazard, the manager should use the facility’s emergency procedure rather than this outage workflow. If the interruption is limited to connectivity, the manager can control it through service-by-service decisions.
Ready.gov advises businesses to pair information-technology recovery planning with business-continuity planning. That distinction matters at a storage facility. The technical team restores technology. The operating team decides what customer-facing work can continue safely while restoration is underway.
Give every service an operating state
“The internet is down” is not an operating decision. A usable outage record gives each service one of five states:
- Available: The service is tested and works through its normal approved path.
- Degraded: The service works, but with a known limitation that can be explained and controlled.
- Local-only: A local function works, but its remote, cloud or synchronization path is unavailable.
- Paused: The approved path is unavailable and no authorized fallback exists.
- Unverified: The manager has not tested the service or cannot determine its current state.
These states prevent two dangerous shortcuts. First, they keep a working local device from being described as fully synchronized when that has not been verified. Second, they prevent a manager from completing a transaction through an improvised path simply because the normal path is unavailable.
Gate access is a good example. If an authorized test shows the local gate controller is accepting valid credentials, the gate may be local-only, not automatically “available.” New access changes may still be paused if the management system cannot reach the controller. A manager should never assume that a change entered during the outage has reached the gate.
Protect customer information when normal tools disappear
Connectivity loss creates pressure to “just write it down.” That pressure needs a firm boundary.
The Federal Trade Commission advises businesses to collect only the sensitive information they need, protect the information they retain and plan ahead for incidents. The Payment Card Industry Security Standards Council is more direct in its merchant guidance: do not store sensitive cardholder data on computers or paper.
That means an outage sheet is not a substitute payment form. It should not contain a full payment-card number, card-verification code, password, government identifier or security answer. It should not become a list of customer access codes. A personal phone, personal email account, unapproved hotspot or consumer note-taking application should not become the new business system.
The safe record is operational. It can capture a pending-item identifier, the customer’s approved account reference if policy permits, the action requested, the time, the accountable employee and the next required step. Sensitive information stays in the approved system and approved payment path.
If a customer wants to make a payment and the approved payment route is unavailable, the honest answer may be that payment processing is temporarily paused. The manager can explain the interruption, provide an approved alternative if one exists, and record a follow-up task without collecting the card data.
Keep five functions separate
During an outage, a manager should review at least five operating functions separately.
1. Access
Test only through the approved procedure. Record whether existing credentials function, whether new access changes can be verified, and whether remote monitoring or intercom support is available. Do not prop a gate open, share master credentials or bypass a security control to restore convenience.
2. Payments and rentals
Pause any transaction that cannot be completed through an approved, secure route. If an authorized alternative exists, use it exactly as written. Do not record card data for later entry, promise that an unprocessed payment is complete or hand over a unit based on an unverified rental.
3. Customer communications
Use the approved business phone, approved status message or other established channel. Give customers the observed service effect and the next review time. Avoid guessing at the cause or promising a restoration time that the provider has not supplied.
4. Security and facility monitoring
Separate local visibility from remote visibility. A camera image on a local monitor does not prove that cloud recording, remote access or alerts are working. If a monitoring function is unavailable, apply the facility’s approved compensating procedure and escalation rule.
5. Work records
Create a numbered pending item for every action that could not be completed in the system. The record should show the requested action, owner, customer effect, approved interim response and reconciliation requirement. It should not claim the transaction occurred.
A fictional 35-minute outage
Consider a fictional facility where the office browser loses connectivity at 10:12 a.m. The manager observes that email, the payment portal and online rental tools are unavailable. The office phone works. An approved test shows existing gate credentials continue to work locally, but the manager cannot verify that new changes will synchronize.
The manager opens the Connectivity Outage Operating-State Record and assigns states. Existing gate access is marked local-only. Payments, new rentals and access changes are paused. The business phone is available. Remote camera access is unverified until the designated owner checks it. The manager records the service-provider ticket number and the next review time without attempting a technical diagnosis.
A customer arrives to rent a unit. The manager explains that the approved rental and payment path is temporarily unavailable, creates a pending-item reference without collecting card data, and offers the approved follow-up option. No unit is released and no payment is represented as complete.
At 10:47 a.m., connectivity returns. The manager does not immediately close the outage. Each paused service is tested through its normal path. The pending rental is reviewed once, the customer is contacted through the approved channel, and the manager checks that no duplicate customer record, charge or access change was created. Only then is the outage record released.
The example does not claim a standard restoration time or describe an actual facility result. Its purpose is to show the sequence: observe, classify, communicate, restore, reconcile.
Restoration is not closure
The return of a browser window proves only that the browser can reach something. Closure requires more.
For every affected service, record the restoration evidence: a successful approved test, a provider notice, a transaction-system status or another source named in company procedure. Then reconcile every pending item against the authoritative system before re-entering it. This check is especially important for payments, rentals and access changes because a delayed request may have completed even when the office did not receive a normal confirmation.
The National Institute of Standards and Technology’s Cybersecurity Framework 2.0 organizes recovery as part of a broader cycle that also includes governance, identification, protection, detection and response. A simple connectivity interruption is not automatically a cybersecurity event, but the recovery discipline is useful: restoration should be verified, communications should be managed, and normal operation should resume from evidence rather than assumption.
The manager can close the record when:
- every service has a tested final state;
- every pending item is completed, canceled or assigned with a due time;
- duplicate charges, rentals and access changes have been checked;
- customer follow-ups are complete or owned;
- the provider or technical ticket is linked; and
- any unexplained security indicator has been escalated through the separate incident process.
Prepare before the next interruption
The best time to define an internet-outage fallback is while the internet works. A manager should know where the approved contact list lives, which phone works independently, which systems have a local mode, what work must pause, what information may be written down, and who can release the facility back to normal operation.
The practical standard is modest: no guessing, no sensitive-data improvisation, no false completion and no orphaned follow-up. A facility does not need every digital service to function normally during an outage. It does need every affected service to have a truthful state, an accountable owner and a safe path back.
Operator tool
Download the Connectivity Outage Operating-State Record as an XLSX workbook or CSV register. A responsive field guide is also provided for browser use. The workbook contains a reader-facing operating view and a detailed reconciliation register. All sample rows are explicitly fictional and must be replaced with facility-approved procedures before use.
Operator companion package
Record the operating state without collecting sensitive data.
The workbook, CSV and responsive field guide contain eight explicitly fictional service rows. They do not connect to a facility system, process payments, diagnose a network or authorize an operating fallback.
Author
Jared Mastroianni is Chief Operating Officer of modSTORAGE and CEO and Founder of Facily.ai. His work focuses on facility operations, multi-location systems, data governance and responsible artificial intelligence.
Sources and limits
- Ready.gov, “Emergency Plans,” accessed September 22, 2026. General business-preparedness guidance supporting continuity planning; it does not prescribe self-storage workflows, service states or outage durations. Open Ready.gov guidance
- Federal Trade Commission, “Protecting Personal Information: A Guide for Business,” accessed September 22, 2026. General U.S. business guidance supporting data minimization and secure handling; it is not legal advice or a facility finding. Open FTC guidance
- PCI Security Standards Council, “Maintaining Payment Security,” accessed September 22, 2026. High-level merchant guidance supporting approved payment paths and non-storage of sensitive cardholder data; operators remain governed by their own processor, acquiring bank, contracts and current obligations. Open PCI SSC guidance
- National Institute of Standards and Technology, “Cybersecurity Framework,” accessed September 22, 2026. Supports bounded recovery discipline; a connectivity outage is not automatically a cybersecurity incident and this article does not claim compliance or certification. Open NIST CSF