If you run a data center, you can produce evidence that your security program exists. You have the policies, the badge system logs, the visitor records, the camera retention, the guard post orders, and a clean SOC 2 report or something like it. What you probably cannot produce is evidence that any of it works, meaning evidence that a person who should be stopped at the mantrap is actually stopped, and a badge that should be dead is actually dead. Knowing whether your data center security program actually works is a different question from knowing whether it is documented, and most operators have only ever answered the second one.
I have spent my career in fields where the difference between a documented control and a working one is measured in consequences, and I have learned to distrust any program that has never been tested by someone trying to beat it. This article is about how to find out where your program stands, using tests you can run with people you already have, and about who in your organization should be running them on a schedule rather than once.
Why a Clean Audit Is Not the Answer
Customer audits are designed to confirm that controls are defined and that evidence of their operation exists. An auditor will ask for your access review, see that one was performed and signed, and mark the control as operating. The auditor will not walk a revoked badge to a cage door, stand at the mantrap during shift change, or pull a random night of footage and check it against the visitor log. Those are tests of effectiveness, and audits are tests of existence. Both matter, and only one tells you whether the building is secure.
The trap is that a clean audit feels like proof. Leadership sees the report, the customers are satisfied, and the question of whether the program works goes unasked for another year. I have seen operators with spotless attestations and contractors holding eighteen-month-old cage access, because the review that satisfied the auditor was a signature on an export rather than an investigation. The audit was accurate. The program was still broken.
The Tests That Tell You the Truth
The first test is the revoked badge. Take a credential that your records show as disabled, ideally one belonging to a contractor whose engagement ended, and have a trusted person present it at the lobby, the mantrap, and a cage door. Every reader should deny it. If any reader accepts it, your revocation process has a break somewhere between the event and the system, and you now know that with certainty instead of assuming otherwise.
The second test is tailgating at the mantrap. Stand where you can see the mantrap at shift change, or review the footage for that window, and count how many people pass on someone else’s credential. Then have a person in ordinary work clothes, carrying a box, approach behind a legitimate badge holder and see whether the holder or the guard stops them. The third test is the escort requirement. Pick a day, pull the visitor log, and match every visitor entry to an assigned escort and a confirmed exit time. Then walk the floor and look for anyone in a vendor shirt who is alone. The fourth is the cameras. Pick a random hour from the previous week and ask whether anyone can tell you, without looking it up, whether the footage from that hour was reviewed by a human for any reason. Most operators discover that the answer is no for every hour of every day.
What the Results Usually Show
When I run these tests for an operator, the findings cluster in the same places. Revoked badges work more often than anyone expects, because the revocation depended on a handoff between procurement, the sponsor, and access control that nobody owned. Tailgating at the mantrap is routine among familiar faces and tolerated by guards who have learned that enforcing it causes complaints. Escort requirements are followed for strangers and waived for regulars. Cameras record everything and are reviewed only after a customer complaint. None of these are technology failures. Every one of them is a failure of someone being assigned to look.
The reason the findings are so consistent is structural. In most data centers physical security reports to facilities, which is measured on uptime and cost, or to a network-focused CISO, who is measured on cyber risk. Neither has a person whose job is to test the building, so the building is never tested, and the program’s condition is unknown to the people accountable for it. That is a leadership gap rather than an operations gap, and it does not close by adding a policy.
Turning Tests Into a Program
A single round of tests gives you a snapshot. A working program tests continuously and treats the results as its primary metric. That means the revoked badge walk happens monthly with a different credential each time. Mantrap observation happens on a rotating schedule that the guard force cannot predict. Visitor log reconciliation happens weekly on a random day. Camera review happens on a defined schedule with specific questions, such as whether every cage entry in a given window matches a credential that should have been there. Each test has an owner, a written result, and a corrective action with a due date when it fails.
The results then go to leadership in the same way cyber metrics do. The COO should see, every quarter, how many revoked credentials still worked, how many tailgating events were observed, and how many escort lapses were found, alongside the trend. When those numbers are visible at the executive level, they start to move, because the people who run the floor learn that someone is watching the outcome rather than the paperwork. That visibility is the single biggest difference between programs that work and programs that pass audits.
Who Should Be Running This
Testing a program requires someone with the standing to run tests that embarrass people, the authority to act on what they find, and the independence to report results candidly to the executive team. That person cannot be the guard supervisor, who is testing his own team, or the facilities director, who is testing his own budget decisions. It needs to be a security leader who owns the whole chain from fence to rack and answers to the COO or CEO. Large operators have that person on staff. Mid-sized operators often do not, and for them a part-time executive security director is the practical way to get a leader who tests without the cost of a full-time executive.
Start this month with the four tests above, run by someone you trust, and write down what you find before anyone has a chance to explain it away. Then ask who in your organization is accountable for making those numbers better next month. If nobody can answer, that is your most important finding. The doctrine I built my career on is that security should be tested rather than assumed, which I lay out in Until Tested: Security Is Only Assumed, and a data center security program that has never been tested by its own leadership is a program whose condition nobody actually knows.
Go Deeper
For a full explanation of how a part-time executive security director fits into an organization like yours, start with What Is a Fractional Security Director? The Complete Guide. My book Fractional Security Director makes the case that most mid-sized organizations have exactly this leadership gap and shows how to close it.
Commissioner William Epps is a former elected Fire Commissioner, federal law-enforcement supervisor, and firefighter since 2006, with instructor credentials in Hazardous Materials response, Active Shooter preparedness, and Stop the Bleed®. He spent seven years in federal law enforcement in physical security, executive protection, and incident command, and now serves organizations as a Fractional Security Director. He is the author of The Spirit of Saul, The Spirit of Pharaoh, and other practical books on security, leadership, and faith, built around one idea: knowledge should be practical enough to use when it matters.
Leave a Reply