At 02:00, the only person in the building is the night guard. The operator is asleep, the NOC does not exist, and the second site is a fantasy. When something goes wrong — a beeping UPS, a burning smell, a dead link — the guard is the entire incident response team until someone wakes up.
Most operators handle this by telling the guard, “Call me if anything looks wrong.” That instruction fails. It fails because “anything” is undefined, because “wrong” is a judgment the guard has not been trained to make, and because a guard who calls about nothing gets scolded while a guard who calls about everything gets ignored. The result is either silence or noise, and neither is a usable report.
The fix is a laminated card taped inside the rack door. It is not a manual. It is a five-minute decision script that turns a non-technical guard into a reliable sensor and a reliable stop-button. The card does not make the guard a technician. It gives them a small, ordered set of things to check, a short list of things never to touch, and a fixed set of facts to report before they call.
Why a card, and not a wiki or a group chat
A wiki page is useless when the power is out and the guard’s phone is at 4% battery. A group chat assumes connectivity that may be the very thing that failed. A phone tree assumes the guard has the numbers memorized or can find them in the dark. A laminated card survives all of these: it needs no power, no login, no signal, and no literacy beyond the script itself.
This is a deliberate downgrade in fidelity and an upgrade in survivability. The card cannot hold the full runbook. It should not try. Its job is to cover the first five minutes — the window in which the wrong action (flipping a breaker, unplugging a storage array, opening a door with smoke behind it) causes more damage than the original fault.
Ready.gov’s business continuity guidance recommends that organizations organize a continuity team and compile a plan to manage disruption, and its planning process includes steps to identify and prioritize risks, define teams and tasks, and test the plan. A rack card is the smallest useful unit of that work: it names the first responder, gives them a bounded task, and gets tested. The full plan can live elsewhere; the card is what the person on site actually holds.
Design constraints that matter more than content
Before writing a single line, accept these constraints. They are not stylistic preferences; they are what makes the card work at 02:00.
- One page, one side. If it needs to be turned over, it will not be read. If it needs two pages, it will be lost.
- Large type. The guard may be reading by phone light or emergency lighting. Ten-point text is invisible.
- Local language first, shared language second. Write the script in the guard’s first language. Put a short version in the operator’s language below it. Translation is cheaper than a misdiagnosis.
- No jargon, no acronyms. “UPS” becomes “the big battery box.” “Switch” becomes “the box with many blinking lights.” If the guard has to decode a term, the card has failed.
- No login required. The card must not depend on a password, a phone app, or a portal. It is paper.
- Three copies. One inside the rack door, one inside the breaker panel cover, one at the guard post. One will go missing. That is normal.
The five-minute script
The script is ordered by irreversibility, not by severity. People first. Then anything that destroys data or hardware. Then service restoration. Then evidence. A guard who follows this order will never make an incident worse, even if they cannot make it better.
Step 1: Confirm what is actually happening (60 seconds)
The card lists four observable conditions. The guard reads them and reports which are true. No interpretation, no diagnosis.
- Is there smoke, fire, or water on the floor?
- Is there a burning smell, a buzzing sound, or a hot surface?
- Are the lights on the equipment off, red, or blinking in a pattern that is different from normal?
- Is the internet or phone service down for the whole building, or only for one device?
These four questions are deliberately binary. The guard does not need to know what a “red light” means. They need to know whether the light is red. The operator interprets.
Step 2: Protect people first (30 seconds)
If there is smoke, fire, or standing water near electrical equipment, the guard does not enter the room. The card says this in plain language: Do not enter. Do not touch the equipment. Leave the building and call the fire service. This is not a technical decision. It is a safety decision, and it is the one place where the card must be absolutely unambiguous.
The card should also state what the guard is not authorized to do: reset breakers, unplug storage, open equipment cases, or pour water on anything electrical. These prohibitions protect the guard from injury and protect the operator from a second, self-inflicted outage.
Step 3: Protect the service second (60 seconds)
If there is no immediate danger, the guard checks whether the problem is power or network. The card gives two simple tests:
- Is the big battery box (UPS) beeping or showing a red light?
- Is the router or switch showing lights on the front?
If the UPS is beeping and the router is dark, the problem is likely power. If the UPS is quiet and the router is dark, the problem is likely the router or the line. The guard does not fix either. They report which one is true.
The card should not ask the guard to reboot anything. A blind reboot can erase logs, interrupt a firmware update, or bring a failing disk back online in a way that destroys data. The guard’s job is to observe and report, not to restore.
Step 4: Preserve evidence (30 seconds)
Before calling, the guard writes down four things on the back of the card or in a notebook kept at the post:
- The time they first noticed the problem.
- Which of the four conditions from Step 1 are true.
- What they can see on the equipment (lights, sounds, smells).
- Whether they touched anything.
This takes thirty seconds and gives the operator a usable report. It also creates a record that can be compared against the next incident. Without it, every event is a new mystery.
Step 5: Escalate with a fixed set of facts (60 seconds)
The card lists the operator’s number first, then a backup number, then the local electrician or ISP. The guard calls in that order. If the first number does not answer within two minutes, they call the second. The card says this explicitly, because a guard who is told “call me” will often call once, get no answer, and then do nothing.
The script for the call is on the card:
“This is [name] at [site]. I am at the rack. The time is [time]. I see [condition]. I have not touched anything. I need you to tell me what to do next.”
That is the whole call. It is short, it is factual, and it gives the operator the three things they need to decide whether to get out of bed: what, where, and whether the guard is safe.
What the card should never say
The card is also a contract. It tells the guard what they are authorized to do and, more importantly, what they are not authorized to do. This protects both the guard and the service.
Never include instructions to:
- Reboot a server, router, or switch.
- Unplug or move storage devices.
- Reset a breaker or replace a fuse.
- Enter a room with smoke, fire, or standing water.
- Open any equipment case.
- Use a fire extinguisher on electrical equipment unless trained.
These prohibitions are not insults to the guard’s intelligence. They are recognition that the guard has not been trained to make these decisions, and that the cost of a wrong decision is higher than the cost of waiting.
How to test the card
A card that has never been tested is a guess. Ready.gov’s continuity planning process includes a step to test the plan; the same applies here. The test is a tabletop walkthrough with the actual night guard, using a hypothetical scenario. It takes twenty minutes.
Sit with the guard. Read the card together. Ask them to walk through what they would do if the UPS started beeping at 02:00. Listen for confusion. If they hesitate at any line, rewrite that line. If they ask a question the card does not answer, add the answer or remove the ambiguity.
Then revise the card after every real event. If the card has not changed in a year, either nothing has happened or nobody is reading it. Both are worth knowing.
What this costs, and when it is wrong
The card costs almost nothing. Printing and laminating three copies is a few hundred naira, shillings, or rupees. The real cost is the hour spent writing it and the twenty minutes spent testing it. That is the trade-off: an hour of the operator’s time in exchange for a guard who can give a usable report instead of a panicked call or silence.
It is wrong under specific conditions. If the site has a trained technician on call within minutes, the card is redundant. If the guard is not literate in any language the operator can write, the card must be replaced with a pictorial version or a phone call to a supervisor who can read it aloud. If the equipment is in a location the guard cannot safely reach, the card should say so and direct the guard to stay away. And if the operator is never reachable by phone, the card needs a different escalation path — a neighbor, a local electrician, or a partner organization — or it is just paper.
The card is not a substitute for a second site, a NOC, or a return policy. It is what you do when you have none of those things and one person on site who deserves a clear, bounded, and safe set of instructions.
Frequently asked questions
What if the guard cannot read?
Use pictures and color codes. A red square next to a drawing of smoke means “leave and call the fire service.” A green circle next to a drawing of a phone means “call this number.” The script can be recorded as a voice memo on a cheap phone and played back. The principle is the same: give a bounded, ordered set of observations and actions that do not require reading.
Should the card include the operator’s number in plain text?
Yes. The guard should not have to unlock a phone, find a contact, and hope the battery is charged. The number should be on the card, in large type, with a backup number below it. If the operator is worried about the number being seen by visitors, use a dedicated SIM for on-call duty and change it if the card is lost.
How often should the card be updated?
After every real incident, and at least once a year. The update should be small: a clarified line, a new phone number, a removed ambiguity. If the card needs a major rewrite, the site’s setup has probably changed enough that the whole script should be revisited.
Does this comply with NIST or any standard?
No. NIST’s Cybersecurity Framework is a voluntary framework for managing cybersecurity risk, and Ready.gov’s continuity guidance is general business advice. Neither requires a rack card. The card is a local practice that borrows the logic of those frameworks — identify risks, define roles, test the plan — and reduces it to a single page that works when nothing else does.
What about the 2.2 billion people who are still offline?
ITU estimates that 2.2 billion people remain offline, and roughly 6 billion, or 74 per cent of the world’s population, were using the Internet in 2025. That context matters because it describes the environment many of these sites operate in: intermittent connectivity is not an edge case, it is the normal condition. A card that assumes connectivity is a card that fails when it is needed most.
The point
The card is not about the guard. It is about the operator. It forces the operator to decide, in advance, what matters, what is safe, and what the first five minutes should look like. That decision is the difference between an incident and a disaster. The guard just reads the card.